Best practices · Security
Browser Security Best Practices
Opens with creditsA practical guide to browser security for web developers. It explains how cross-site scripting happens in modern frameworks and how Trusted Types and a strict Content Security Policy contain it, how to configure CORS without opening your API, which cookie attributes and prefixes to use, how to stop CSRF and clickjacking, which security headers matter, and how to load third-party scripts and talk between windows safely.
Written by Tauseef Fayyaz7 chapters, 22 practicesAbout 22 min24 quiz questionsReviewed 13 October 2026What you will learn
7 chapters · about 22 min
1Cross-site scripting and Trusted TypesHow XSS gets into apps built with modern frameworks, the code patterns that prevent it, and how Trusted Types lets the browser enforce those patterns for you.4 practices · 4 min
2Content Security PolicyA strict Content Security Policy tells the browser which scripts may run, so an injected one does not. These practices get you to a strict policy without breaking the site.3 practices · 3 min
- CORS done rightCORS does not protect your API; it relaxes the same-origin policy for origins you name. These practices keep that relaxation narrow.3 practices · 3 minOpens with credits
- CookiesCookie attributes decide which requests carry your session and which code can read it. Small settings here close entire classes of attack.3 practices · 3 minOpens with credits
- Cross-site request forgeryCSRF tricks a signed-in user's browser into sending a request they did not mean to. These are the defenses OWASP recommends, in the order to reach for them.3 practices · 3 minOpens with credits
- Framing, HSTS and security headersA handful of response headers switch on protections the browser already has: no framing, HTTPS only, no content sniffing, fewer referrer leaks and isolated windows.3 practices · 3 minOpens with credits
- Third-party scripts and cross-window messagingEvery script you include runs with your page's full power, and every window you talk to could be someone else's. Load less, pin what you load, and check who is talking.3 practices · 3 minOpens with credits
About this guide
Browser security is about the rules the browser enforces on your behalf, and the headers and code that tell it what to enforce. The browser already isolates sites from each other with the same-origin policy. Most front-end vulnerabilities come from weakening that isolation by accident: a CORS header that trusts every origin, a cookie sent on cross-site requests, a page that any site can frame, or a string that ends up in innerHTML and runs as script.
Cross-site scripting is still the biggest single issue. OWASP's Top 10:2025 counts it inside Injection, where cross-site scripting alone accounts for more than 30,000 CVEs. Modern frameworks escape output by default, so today's XSS mostly comes through escape hatches, DOM APIs and URLs. The good news is that browsers now offer strong defenses in depth: a nonce-based Content Security Policy, and Trusted Types, which MDN lists as Baseline 2026, available across current major browsers since February 2026.
This guide works through the browser's security model layer by layer. It starts with XSS and Trusted Types, then Content Security Policy, CORS, cookies, CSRF, framing and the rest of the security headers, and ends with third-party scripts and cross-window messaging. Each practice explains why it matters and shows the exact header or code to use. The advice follows the OWASP Cheat Sheet Series and MDN's web security documentation. Server-side injection, authorization and sign-in each have their own guides.
Common questions
What is the most important browser security header?
A strict Content Security Policy does the most, because it stops injected scripts from running. Pair it with HSTS for HTTPS, frame-ancestors against clickjacking, X-Content-Type-Options: nosniff and a Referrer-Policy. Cookie attributes matter just as much for sessions, even though they are not a separate header.
Does CORS protect my API from attackers?
No. CORS is a way to let other origins read your responses in a browser. It does not stop requests from being sent and does not apply to non-browser clients. Your API still needs authentication, authorization and CSRF protection; CORS should only name the exact origins that need access.
Is SameSite=Lax enough to prevent CSRF?
OWASP treats SameSite as defense in depth. Lax still sends cookies on top-level GET navigations, it works at the registrable domain rather than the exact origin, and it does not stop client-side CSRF. Use your framework's CSRF tokens or a Fetch Metadata check as the main control.
What are Trusted Types?
Trusted Types is a browser API that blocks plain strings from reaching dangerous DOM sinks like innerHTML and script URLs. With the CSP directive require-trusted-types-for 'script', only values created by policies you define are accepted. MDN lists it as Baseline 2026, available across current major browsers since February 2026.
Should I use a nonce or a hash for my Content Security Policy?
Use a nonce when pages are rendered per request, generating a new one for every response. Use hashes when pages are static or cached, since a nonce cannot change on cached HTML. Both work with strict-dynamic so trusted scripts can load your bundles.
Is X-Frame-Options still needed?
The CSP frame-ancestors directive replaces it, and browsers ignore X-Frame-Options when frame-ancestors is set. Sending X-Frame-Options: DENY as well is harmless and covers older browsers, which is why OWASP still lists it.
Sources (8)
Checked against these, last on 13 October 2026.
- Cross Site Scripting Prevention Cheat Sheet, OWASP Cheat Sheet Seriescheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
- Trusted Types API, MDN Web Docsdeveloper.mozilla.org/en-US/docs/Web/API/Trusted_Types_API
- Content Security Policy Cheat Sheet, OWASP Cheat Sheet Seriescheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
- Cross-Origin Resource Sharing (CORS), MDN Web Docsdeveloper.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS
- Set-Cookie header, MDN Web Docsdeveloper.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie
- Cross-Site Request Forgery Prevention Cheat Sheet, OWASP Cheat Sheet Seriescheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
- HTTP Strict Transport Security Cheat Sheet, OWASP Cheat Sheet Seriescheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html
- HTTP Security Response Headers Cheat Sheet, OWASP Cheat Sheet Seriescheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html
Related on Sefism
Picked from the other libraries by shared topics.
Roadmaps
See allCheat sheets
See allBest practices
See all- Authentication Best PracticesBuild sign-in that holds up: password rules from NIST, Argon2id hashing, login throttling, MFA and passkeys, secure sessions and safe account recovery.
- Authorization Best PracticesGet access control right: deny by default, object-level checks against IDOR, RBAC vs ABAC vs ReBAC, tenant isolation with row-level security, audits and tests.
- Secrets Management Best PracticesKeep API keys, passwords and tokens out of git, logs and browser bundles: secret managers, scanning, rotation, OIDC in CI and leak response.
Checklists
See all- Web Application Security ChecklistA practical web application security checklist built on the OWASP Top 10:2025 and ASVS 5.0, with a severity and a way to verify every check.
- API Security ChecklistCheck your REST or GraphQL API against the OWASP API Security Top 10: authentication, object authorization, rate limits, input validation, SSRF, CORS and logging.
- Linux Server Hardening ChecklistHarden an Ubuntu, Debian or RHEL server step by step: accounts and sudo, SSH, updates, firewall and open ports, permissions, logging and CIS benchmark scans.
Project structures
See all- Electron desktop app project structureA desktop notes app for Windows, macOS and Linux, built from the Electron Forge 8 Vite and TypeScript template. The tree starts with the scaffold's three entry files (main, preload, renderer) and grows into separate folders for each process, a typed IPC contract, signed installers, auto-update and end-to-end tests on the packaged app. For students who know web development and want to ship a real desktop app; if a small download matters more than a large JavaScript ecosystem, Tauri is the alternative worth comparing first.
- Firebase (Cloud Functions and security rules) project structureFor students building an app on Firebase who need a real backend: Cloud Functions (2nd gen) in TypeScript, Firestore and Storage security rules with tests, and the Local Emulator Suite. The tree starts from
firebase initand grows into feature folders of callables, triggers and scheduled jobs, then adds CI deploys, environments, contract tests and runbooks. - AI agent with an MCP server project structureFor developers who want to give AI assistants safe access to their own data or API. A TypeScript MCP server built on the official SDK, organised by feature (tasks, projects) with each feature owning its tools, resources and prompts, served over stdio for local hosts and Streamable HTTP with OAuth for remote ones, plus a small agent and the evals that prove a model can use it.
Career questions
See all- How do I get into AI security as a student or junior engineer?Build a normal security or software foundation first, then learn how LLM apps fail using the OWASP Top 10 for LLM Applications and MITRE ATLAS, and prove it by building, testing and hardening a small LLM app of your own. Most people reach AI security through AppSec, security engineering or ML engineering, not straight from university.
- Where do I start if I want a career in cybersecurity or IT operations?Start with the foundations both fields share: networking, Linux, and how systems fail. Then choose an entry role such as SOC analyst, IT support or junior cloud operations, and prove it with hands-on labs and one documented project rather than a stack of certificates.
- Can I use AI coding tools at my internship, and what should I never paste into them?Usually yes, but only the tools your company has approved, on the code and data they allow, and in the way they allow. Ask in your first week. Never paste secrets, customer data or code you are not permitted to share, and review everything the tool writes as if your name is on it, because it is.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com