frontend-security

Frontend security

Server-side review misses the frontend because the frontend "has no secrets" — and then a service-role key ships in a NEXT_PUBLIC_* var, a markdown renderer writes raw HTML into the DOM, and an access token sits in localStorage where any injected script can read it. This skill is the client-side pass: the sinks, the storage, the headers, and what to verify before calling it done.

When to activate

• Rendering anything a user or an API supplied (HTML, markdown, SVG, URLs, filenames).
• Auth in the browser: login, logout, token refresh, "remember me", role-based UI.
• Adding an env var, an analytics/chat/payment script, an iframe, or a postMessage channel.
• Reviewing a PR that touches any of the above, or a "make it work in the browser" fix.

The five checks, in order

1. Secrets — no key that grants privilege may reach the bundle.
2. Sinks — every place a string becomes markup, a URL, or code.
3. Token storage — where credentials live between requests.
4. Headers — CSP and friends, set where the app is actually served from.
5. Third-party — scripts, iframes, and messages you did not write.

1. Secrets in the bundle

• A var is public the moment its name is prefixed (NEXT_PUBLIC_, VITE_, PUBLIC_, REACT_APP_, EXPO_PUBLIC_) or referenced from a client component. Prefixing a server key does not make it safe — it publishes it.
• Never prefix: service-role keys, admin/API secrets, webhook signing secrets, SMTP or DB credentials, private OAuth client secrets. See secrets-hygiene.
• Grep before shipping: NEXT_PUBLIC_.*(SERVICE|SECRET|PRIVATE|ADMIN|TOKEN|PASSWORD), and search the built output (.next/static, dist/assets) for the last 8 characters of any server key you hold. A hit in the build is a leak, not a warning.
• Anything the browser can call, an attacker can call with the same key. If a key must stay secret, the call belongs in a route handler / server action / edge function, and the client calls that.