Bài này nói về bảo mật frontend mức senior cho phỏng vấn: threat model, không phải list helper escapeHTML. Nó nói XSS cùng origin cướp được gì, site độc hại khác làm được gì với cookie, client bundle đã lộ gì, và bạn đã tin gì từ npm. Dành cho engineer đã ship Vue 3 / Nuxt, giờ cần ra quyết định dưới attacker thật, không phải câu “mình dùng HTTPS”.

Đọc 10.1–10.3 trước (XSS, CSRF, authentication). Người phỏng vấn xoáy chỗ cất token và v-html nhiều hơn trivia CORS. Rồi 10.4–10.7 cho validation khác sanitization, CORS như quyền đọc của trình duyệt, supply chain, và secret Vite/Nuxt. Nêu rõ attacker, sink, và control, không phải list header cho có.

Tóm tắt: XSS (cross-site scripting) là HTML hoặc JS của attacker chạy trong origin của bạn. Stored nằm trong DB. Reflected được server echo từ request. DOM-based là client đọc location / postMessage rồi đưa vào sink. Vue escape {{ }}; không escape v-html.

Vì sao quan trọng: alert(1) chỉ là demo. Bug thật là cướp token khi access token nằm trong localStorage (xem Best practices về authentication). Một field CMS dùng v-html là session bị cắp, không phải popup.

1. Cách hoạt động: Stored: payload được lưu (comment, tên hiển thị, khối CMS) rồi mọi người xem sau đều dính. Reflected: server echo q từ URL vào HTML. Search SSR vẫn làm vậy. DOM-based: innerHTML = location.hash không đụng tới server.
2. Compiler của Vue ghi interpolation thành text. v-html, innerHTML của widget, href javascript:, và el.innerHTML = props.code vẫn là sink. Sanitize ở ranh giới bằng DOMPurify, không phải regex. Sanitize cuối để không dính lại mutation XSS.
3. CSP (Content Security Policy) là containment: script-src không 'unsafe-inline', Report-Only trước, header chứ không phải <meta> gắn muộn. CSP không thay sanitization và không chặn navigation javascript:.

<script setup lang="ts">
import DOMPurify from 'dompurify'
const dirty = inject('cmsHtml') as string
// Chỉ profile HTML, đừng cho SVG/MathML trừ khi cố ý
const html = DOMPurify.sanitize(dirty, { USE_PROFILES: { html: true } })
</script>
<template>
  <p>{{ dirty }}</p> <!-- text đã escape, không phải sink -->
  <div v-html="html" /> <!-- sink: chỉ sau DOMPurify -->
</template>
// Cũng allowlist protocol href. javascript: là XSS lúc navigate.

Điều gì xảy ra: {{ dirty }} không chạy script được. v-html thì được, nên HTML duy nhất tới DOM đã qua profile HTML của DOMPurify. Đồng nghiệp gán el.innerHTML = props.code là bỏ qua Vue hoàn toàn. Ghép với token mà JS không đọc được (10.3).

Lỗi hay gặp

• Triệu chứng: alert(1) “chỉ là popup”. Nguyên nhân: coi XSS như demo. Cách xử lý: nêu rõ session bị cắp.
• Triệu chứng: “Vue an toàn”. Nguyên nhân: bỏ qua v-html / innerHTML. Cách xử lý: audit mọi sink.
• Triệu chứng: CSP <meta> muộn, vẫn script inline. Nguyên nhân: không phải header, còn unsafe-inline. Cách xử lý: header Report-Only trước.
• Triệu chứng: sanitizer rồi nối chuỗi vào HTML. Nguyên nhân: mutation XSS. Cách xử lý: sanitize cuối.

Tóm tắt: CSRF (cross-site request forgery) là trang độc hại kích request đổi state mà trình duyệt tự gắn cookie. Bearer token do JS gắn lên header thì không tự gắn. Cookie gây CSRF; custom header và SameSite là cách chống.

Vì sao quan trọng: “Mình là SPA, CSRF biến mất” là miss thường gặp. Nó biến mất chỉ khi không có gì tự gắn: không cookie session, không cookie refresh tự POST /logout. Login cookie kèm Access-Control-Allow-Origin: * và credentials là CSRF thêm vài bước (xem 10.5).

1. Cách hoạt động: Nạn nhân đã login. Trang của attacker submit POST (hoặc GET đổi state). Trình duyệt gắn cookie của nạn nhân cho API của bạn. Không cần XSS trên origin của bạn.
2. SameSite=Lax (mặc định SPA thường) không gửi cookie trên POST xuyên site, vẫn gửi trên GET top-level. Đổi state trên GET (/logout, /unsubscribe) vẫn là CSRF với Lax. Strict cũng không gửi cookie ở navigation inbound đầu từ email. None; Secure cho embed và cần thêm control.
3. Header tùy chỉnh (X-Requested-With) buộc preflight CORS mà trang lạ không qua được. Token double-submit thì ổn; chúng không sống sót XSS. JWT trong header Authorization từ memory không tự gắn, đến khi ai đó cất nó, hoặc cookie refresh vẫn đổi state không cần header. Xem Authentication.

// Session cookie: header tùy chỉnh là control CSRF (không phải secret)
await api.post('/orders', body, {
  headers: { 'X-Requested-With': 'XMLHttpRequest' },
  withCredentials: true,
})
// Flag cookie (Set-Cookie từ API):
// HttpOnly; Secure; SameSite=Lax; Path=/
// Mutation là POST. GET /logout vẫn là CSRF với Lax.
// Bearer từ memory: bỏ withCredentials; CSRF thường N/A.

Điều gì xảy ra: Cookie đi cùng POST vì withCredentials đang bật. Header tùy chỉnh buộc một preflight. Form HTML lạ không gán X-Requested-With được, nên preflight fail. Nếu đây là header Bearer lấy từ memory, trang lạ không gắn được token từ đầu.

Lỗi hay gặp

• Triệu chứng: “SPA nên không CSRF”. Nguyên nhân: cookie session hoặc refresh vẫn tự gắn. Cách xử lý: nêu rõ cookie.
• Triệu chứng: logout từ preview email. Nguyên nhân: GET /logout dưới Lax. Cách xử lý: POST + xác nhận.
• Triệu chứng: CORS * + credentials. Nguyên nhân: coi CORS như tường. Cách xử lý: origin cụ thể; xem 10.5.
• Triệu chứng: double-submit sau XSS. Nguyên nhân: JS đọc token được. Cách xử lý: sửa XSS; đừng coi token là lớp phòng thủ.

Tóm tắt: Ưu tiên cookie session httpOnly, hoặc access token trong memory kèm cookie refresh httpOnly. Đừng mặc định access token vào localStorage. Rotate refresh mỗi lần dùng. Single-flight các 401 để một burst không thu hồi cả family. Broadcast logout sang mọi tab.

Vì sao quan trọng: XSS kèm token JS đọc được là session bị cắp (10.1). 401 song song không hàng đợi sẽ rotate family refresh và đá hết tab trừ một. Hàng đợi 401 và redirect nằm ở Xử lý 401.

1. Cách hoạt động: Cookie session: server nắm session; JS không cướp được; CSRF giờ là việc của bạn (10.2). Access token trong memory + refresh httpOnly: XSS không đọc được cookie refresh; reload phải refresh; CSRF áp vào endpoint refresh.
2. Rotate refresh lúc dùng: token bị cắp dùng được một lần. Dùng lại refresh cũ nên thu hồi cả family. Interceptor 401 single-flight một lần refresh, waiter retry. Xem practical-questions 18.1.
3. Logout: server thu hồi kèm BroadcastChannel (hoặc event storage) để mọi tab bỏ memory. Persist Pinia của user store chỉ là localStorage thêm vài bước. Mình không implement OAuth implicit trong SPA.

let refreshInFlight: Promise<string> | null = null
async function refreshAccess(): Promise<string> {
  if (!refreshInFlight) {
    refreshInFlight = api.post('/auth/refresh').then((r) => {
      tokenMemory.set(r.accessToken)
      return r.accessToken
    }).finally(() => { refreshInFlight = null })
  }
  return refreshInFlight // các waiter share một round-trip
}
const authCh = new BroadcastChannel('auth')
export function logoutAllTabs() {
  tokenMemory.set(null)
  authCh.postMessage({ type: 'logout' })
  void api.post('/auth/logout')
}

Điều gì xảy ra: Mười 401 share một /auth/refresh. Không có promise, rotation đá hết tab trừ một. Logout xóa memory ở tab này và các tab khác, rồi nhờ server thu hồi. Access token không đụng Web Storage.

Lỗi hay gặp

• Triệu chứng: session bị cắp sau một XSS. Nguyên nhân: access token trong localStorage. Cách xử lý: memory hoặc cookie httpOnly.
• Triệu chứng: mọi tab trừ một bị logout. Nguyên nhân: 401 song song, mỗi cái rotate refresh. Cách xử lý: single-flight.
• Triệu chứng: một tab logout, tab khác vẫn vào. Nguyên nhân: không broadcast / không thu hồi phía server. Cách xử lý: BroadcastChannel + /auth/logout.
• Triệu chứng: “localStorage mã hóa”. Nguyên nhân: XSS cùng origin giải mã được. Cách xử lý: đừng cất access token ở đó.

Tóm tắt: Validation hỏi “đây có phải order?” Sanitization hỏi “HTML này render có an toàn?” Encoding là cách nhét chuỗi vào một ngữ cảnh (text HTML, URL, JS). Check phía client là UX. Check phía server mới là ranh giới bảo mật.

Vì sao quan trọng: Regex trên form checkout không chặn role: 'admin' trong body. Bỏ Zod trong handler Nitro “vì TypeScript” là bug bảo mật: type biến mất lúc runtime. Sanitize HTML không làm email hợp lệ; markdown hợp lệ vẫn có thể là XSS (10.1).

1. Cách hoạt động: Share một schema Zod (hoặc Valibot) khi bạn phụ trách cả hai phía. Form dùng safeParse cho lỗi field. Handler Nitro dùng .parse trên readBody và vẫn làm authz: body đã parse không được gán isAdmin hay price.
2. Sanitize HTML bằng DOMPurify ở ranh giới render (10.1). Đừng “sửa” chuỗi bẩn thành data nghiệp vụ. Encoding theo ngữ cảnh: {{ }} của Vue encode text HTML; nó không encode URL hay chuỗi JS bạn tự ghép.
3. SQL/NoSQL injection là việc parameterized query / ORM trên server. Frontend không chặn được. Allowlist thắng blocklist. Đừng lấy price, role, hay discount từ client.

const createOrderSchema = z.object({
  sku: z.string().min(1).max(64),
  qty: z.number().int().positive().max(99),
  // không bao giờ: price, role, isAdmin. Đó là fact phía server
})
// Client: UX. Hiện lỗi field. Form bị bypass vẫn đụng API.
const parsed = createOrderSchema.safeParse(form)
if (!parsed.success) return parsed.error.flatten()
// Server (Nitro): ranh giới. TypeScript biến mất lúc runtime.
const body = createOrderSchema.parse(await readBody(event))
// authz vẫn: body.sku không phải quyền mua

Điều gì xảy ra: Cùng schema từ chối qty không hợp lệ trên form lẫn trên server. POST tự chế bỏ qua form vẫn fail .parse. price vắng mặt có chủ đích: server tự tra. TypeScript trên handler lẽ ra đã nhận role: 'admin' như any.

Lỗi hay gặp

• Triệu chứng: API tin role từ body. Nguyên nhân: validation không authz. Cách xử lý: bỏ role phía client; lấy từ session.
• Triệu chứng: “TypeScript trên handler”. Nguyên nhân: không parse lúc runtime. Cách xử lý: .parse Zod/Valibot.
• Triệu chứng: sanitizer “sửa” SKU. Nguyên nhân: sửa thành data nghiệp vụ. Cách xử lý: reject; đừng đoán.
• Triệu chứng: frontend “chặn SQL injection”. Nguyên nhân: nhầm với encoding. Cách xử lý: parameterized query trên server.

Tóm tắt: CORS (Cross-Origin Resource Sharing) là quyền đọc của trình duyệt. Nó không bảo vệ API khỏi curl. HTTPS là HSTS và cookie Secure ở edge, không phải redirect Vue Router. API dùng cookie không bao giờ ghép credentials với Access-Control-Allow-Origin: *.

Vì sao quan trọng: Người phỏng vấn đánh trượt câu “CORS là lớp bảo mật của ta”. Thiếu Vary: Origin, * kèm credentials, hoặc redirect HTTP→HTTPS chỉ trong Vue sẽ hiện thành “cookie biến mất trên prod” hoặc cảnh báo mixed-content, chứ không phải câu lý thuyết.

1. Cách hoạt động: JS chỉ đọc được response cross-origin khi server opt-in. Request đơn giản (GET/POST kiểu form, không custom header) bỏ preflight. application/json và X-Requested-With thì trigger OPTIONS. Trang lạ không đọc body nếu thiếu Allow-Origin đúng.
2. Credentials (withCredentials / credentials: 'include') cần origin cụ thể, không phải *. Reflect Origin theo allow-list rồi gửi Vary: Origin. Authz thật nằm ở session và check quyền. CORS không phải ACL.
3. HTTPS: HSTS ở edge, cookie Secure, không mixed content. Redirect Vue Router không set HSTS và không chặn request HTTP đầu tiên. BFF cùng origin thì gần như khỏi bàn chuyện này.

const allow = new Set(['https://app.example.com', 'https://admin.example.com'])
res.setHeader('Vary', 'Origin')
if (origin && allow.has(origin)) {
  res.setHeader('Access-Control-Allow-Origin', origin) // không bao giờ *
  res.setHeader('Access-Control-Allow-Credentials', 'true')
  res.setHeader('Access-Control-Allow-Headers', 'Content-Type, X-Requested-With')
  res.setHeader('Access-Control-Allow-Methods', 'GET,POST,PUT,PATCH,DELETE')
}
// curl bỏ qua block này. Authz là session, không phải mấy header này.

Điều gì xảy ra: Chỉ hai origin đọc được response có credentials. Vary: Origin ngăn cache đưa ACAO của app sang admin. curl vẫn chạy được: đó mới là ý của “CORS không phải tường”. Kèm CSRF control khi cookie được gắn (10.2).

Lỗi hay gặp

• Triệu chứng: cookie thiếu chỉ trên trình duyệt. Nguyên nhân: * + credentials, hoặc thiếu Allow-Credentials. Cách xử lý: origin cụ thể.
• Triệu chứng: chạy được localhost, fail trên prod. Nguyên nhân: không Vary: Origin / allow-list sai. Cách xử lý: preview origin prod.
• Triệu chứng: “mình redirect sang HTTPS trong Vue”. Nguyên nhân: request HTTP đầu vẫn xảy ra. Cách xử lý: HSTS ở edge.
• Triệu chứng: coi CORS như ACL. Nguyên nhân: nhầm policy trình duyệt với authz. Cách xử lý: check session; curl để thử.

Tóm tắt: Supply chain là mọi thứ chạy vì bạn đã cài: lockfile, script lúc install, plugin Vite/Nuxt, và thẻ <script> third-party. Commit lockfile. Install frozen trên CI. Coi npm audit là tín hiệu ồn. Pin những thứ reachable. SRI (Subresource Integrity) cho script bạn không bundle.

Vì sao quan trọng: Xóa package-lock.json để “sửa conflict” là cách event-stream xảy ra lại. Helper CSS 10 dòng với preinstall: curl | sh là RCE lúc build. Plugin Vite bị compromise chạy trên máy bạn và trên CI, không chỉ trên trình duyệt. npm audit --force vào Friday có thể gãy Vue.

1. Cách hoạt động: Commit package-lock.json / pnpm-lock.yaml. CI dùng npm ci / pnpm i --frozen-lockfile. Review PR chỉ lockfile như supply chain, không phải “không có code app”.
2. npm audit báo CVE đã biết. Không có nghĩa path đó reachable từ app. Triage: khai thác được không, path đó có ship ra client không, rồi pin / override / thay. Đừng --force một major Vue chỉ để im một transitive.
3. Provenance (npm audit signatures / sigstore) chứng nhận ai publish, không phải code an toàn. Pin version cụ thể cho dep rủi ro. Bỏ script lúc CI (ignore-scripts) trừ khi đã allow-list. SRI hash script CDN. Plugin Vite là niềm tin lúc build.

<!-- Script third-party: pin URL và bắt buộc hash -->
<script
  src="https://cdn.example.com/analytics@1.4.2.js"
  integrity="sha384-OQin2XLpTiFXgcs5Ar4jRCU8BLTAzqI3T1M1zN9z5F2eH0pQ=="
  crossorigin="anonymous"
></script>
<!-- package.json: đừng xóa lockfile để “giải quyết” conflict -->
<!-- CI: npm ci --ignore-scripts  (allow-list build tool riêng) -->
<!-- preinstall của plugin Vite là RCE. Đọc package trước khi thêm. -->

Điều gì xảy ra: File CDN phải khớp hash, không thì trình duyệt từ chối. Account CDN bị cắp không đổi được script nếu không đổi luôn HTML bạn đang kiểm soát. Comment chính là policy lúc cài: lockfile frozen, không preinstall bất ngờ, hãy đọc plugin.

Lỗi hay gặp

• Triệu chứng: PR “nhỏ” thêm SDK cloud. Nguyên nhân: không đọc script lúc cài. Cách xử lý: npm pack --dry-run và field preinstall.
• Triệu chứng: xóa lockfile để merge. Nguyên nhân: coi nó như nhiễu generate. Cách xử lý: generate lại cùng package manager, commit.
• Triệu chứng: audit --force vào Friday. Nguyên nhân: dùng audit như gate. Cách xử lý: triage reachability; pin; lên lịch major.
• Triệu chứng: script CDN không SRI. Nguyên nhân: cho tiện. Cách xử lý: hash kèm version ghim trong URL.

Tóm tắt: Mọi thứ có prefix VITE_ hoặc nằm trong runtimeConfig.public / NUXT_PUBLIC_ không phải secret. Vite và Nuxt inline nó vào client bundle. .env không phải ranh giới bí mật. Key chỉ-server nằm ở Nitro, CI, hoặc BFF.

Vì sao quan trọng: “Để key Stripe trong .env” là bẫy phỏng vấn. VITE_STRIPE_SECRET thành chuỗi trong dist. Return runtimeConfig private từ composable thì đổ hết vào window.__NUXT__. rg trên dist sau khi lộ, rồi rotate, là cách xử lý incident.

1. Cách hoạt động: Vite thay import.meta.env.VITE_* lúc build. Env không prefix thì undefined trên trình duyệt. Đừng “sửa” bằng cách thêm VITE_. Key publishable (pk_, token public Mapbox) được phép công khai; key secret (sk_, URL DB, webhook Slack) thì không.
2. Nuxt: runtimeConfig.stripeSecret chỉ chạy trên server (NUXT_STRIPE_SECRET). runtimeConfig.public.stripePk là phía client (NUXT_PUBLIC_STRIPE_PK). Composable nào return cả useRuntimeConfig() khi có key chỉ-server thì secret lộ vào payload.
3. Secret CI nằm trong vault của provider, không trong repo, không trong console.log của plugin. Sau khi lộ: rotate, grep dist và artifact cũ, rồi thêm check CI fail khi gặp prefix secret đã biết trong client bundle.

// nuxt.config.ts: cách hiểu
runtimeConfig: {
  stripeSecret: '', // chỉ-server; env NUXT_STRIPE_SECRET
  public: {
    stripePk: '', // client; env NUXT_PUBLIC_STRIPE_PK
  },
}
// Vite: chỉ VITE_* được đưa vào code client
const publishable = import.meta.env.VITE_MAPBOX_TOKEN // OK nếu publishable
// import.meta.env.DATABASE_URL là undefined trên trình duyệt
// đừng "sửa" bằng cách thêm prefix VITE_
// Lộ: VITE_STRIPE_SECRET trong dist → rotate key Stripe

Điều gì xảy ra: stripeSecret không bao giờ được để trong <script setup> chạy trên client. stripePk thì được: đó là key publishable. Thêm prefix VITE_ vào DATABASE_URL vì nó undefined trên trình duyệt là cách credential DB production lọt vào dist.

Lỗi hay gặp

• Triệu chứng: VITE_STRIPE_SECRET trong dist. Nguyên nhân: gắn prefix cho secret để trình duyệt thấy được. Cách xử lý: rotate; chuyển sang Nitro/BFF.
• Triệu chứng: DATABASE_URL undefined trên client. Nguyên nhân: đúng vậy. Cách xử lý: đừng thêm VITE_.
• Triệu chứng: secret trong window.__NUXT__. Nguyên nhân: return cả useRuntimeConfig(). Cách xử lý: chỉ return field public.
• Triệu chứng: .env trong git. Nguyên nhân: coi file đó là private. Cách xử lý: gitignore, rotate mọi thứ từng nằm ở đó.