7 JavaScript Security Patterns That Secure My Apps

I stopped worrying about XSS, CSRF, and injection — these patterns lock it down.

I remember the exact moment I stopped sleeping well. It was 3 AM, and I was staring at my screen, reading about a massive data breach at a company I admired. The attack vector? A simple, overlooked XSS vulnerability that someone had dismissed as “theoretical.”

Theoretical vulnerabilities have a nasty habit of becoming practical breaches.

For years, I treated security like a checklist item — something I’d get to “later.” Then I realized that “later” was when attackers were already probing my applications. According to OWASP, Cross-Site Scripting (XSS) consistently ranks among the top web security vulnerabilities. It’s not a theoretical problem. It’s the reason your users’ data gets stolen.

So I built a security-first mindset. Not by becoming a paranoid developer, but by adopting seven battle-tested patterns that lock down my applications without turning every code review into a security audit.

Here’s what I learned.

1. Content Security Policy (CSP): Your Application’s Bouncer

Think of CSP as the bouncer at an exclusive club. It doesn’t matter if someone has a fake ID (malicious script) if the bouncer checks every single person before they enter.

CSP is a browser security standard that controls which resources your application is allowed to load. It’s your first line of defense against XSS because it tells the browser: “Only execute scripts from these trusted sources, and nothing else.”

Here’s the pattern that actually works: strict CSP with nonces. A nonce (number used once) is a unique, unpredictable token generated for each HTTP response. Your server generates it, embeds it in both the CSP header and the script tags, and the browser only executes scripts that match the nonce. Attackers can’t predict the nonce, so they can’t inject malicious scripts.

The mistake most developers make: They use 'unsafe-inline' and 'unsafe-eval' in their CSP, which completely defeats the purpose. It's like hiring a bouncer and telling them to let everyone in anyway.

The shift: CSP doesn’t prevent your application from having vulnerabilities — but it makes those vulnerabilities significantly harder to exploit. It’s your safety net when everything else fails.

2. Input Validation and Sanitization: Trust Nothing, Verify Everything

Here’s a hard truth: every piece of user input is potentially malicious. Every single one.

The pattern is simple but requires discipline: validate on both client and server, sanitize before processing or displaying, and use whitelists, not blacklists.

Validation checks if the input meets expected criteria. Is it the right type? The right format? Within acceptable bounds? If not, reject it immediately.

Sanitization removes or escapes potentially dangerous characters from data before it’s processed or displayed. This prevents XSS, SQL injection, and other injection attacks.

The mistake most developers make: Relying solely on client-side validation. Client-side validation is for user experience, not security. An attacker can bypass it trivially.

The pattern that works: Combine validation, escaping, and sanitization libraries. Use a library like DOMPurify for HTML sanitization, validate data types before sanitization, and use parameterized queries for database operations.

3. Trusted Types: The New Sheriff in Town

Trusted Types is a modern JavaScript API that gives you a way to ensure that input has been passed through a user-specified transformation function before being passed to an API that might execute that input.

Think of it as a gatekeeper for dangerous DOM APIs. Instead of allowing any string to be passed to innerHTML or eval, Trusted Types forces you to create a Trusted Type object first. This ensures that data is sanitized before it reaches an injection sink.

The pattern: Enforce Trusted Types via CSP directives. This creates a layered defense: the CSP enforces the policy, and the Trusted Types API enforces the sanitization.

Why this matters: XSS persists because the context, parser, and framework edges are complex. Trusted Types simplifies this by making sanitization mandatory at the API level. Treat every user-influenced string as untrusted until it is strictly encoded for the exact sink and guarded by runtime policy.

4. CSRF Protection: Because Your Users Aren’t the Only Ones Clicking Buttons

Cross-Site Request Forgery (CSRF) is the attack that tricks your users into performing actions they didn’t intend. XSS hijacks user trust; CSRF hijacks user intent.

The pattern: synchronizer token pattern (also known as anti-CSRF tokens). You generate a secret, unpredictable token for each form or state-changing request. You include it as a hidden field in the form. When the request is submitted, you validate that the token matches.

The implementation that works: Use a library like small-csrf or edge-csrf that implements the OWASP Signed Double-Submit Cookie pattern. This binds CSRF tokens to user sessions using HMAC signatures for enhanced security.

The mistake most developers make: Not protecting AJAX requests. Anti-CSRF tokens being accessible to JavaScript is a controlled and necessary implementation for secure CSRF protection in AJAX-based workflows. It does not expose credentials or allow authentication bypass.

5. Secure Cookies: The Silent Guardian

Cookies are how your application remembers who your users are. They’re also how attackers steal sessions.

The pattern is straightforward but often ignored: set the right attributes on your cookies.

• HttpOnly: Prevents JavaScript from accessing the cookie. If an attacker injects XSS, they can’t steal the session cookie because JavaScript can’t read it.
• Secure: Ensures the cookie is only sent over HTTPS.
• SameSite: Prevents the cookie from being sent with cross-site requests, mitigating CSRF attacks.

The mistake most developers make: Not using all three together. Each attribute protects against a different attack vector. Together, they form a robust defense.

Why this matters: Preventing all flavors of XSS is usually the toughest part of hardening a system. HttpOnly cookies reduce the impact of XSS by protecting the session cookie even if an injection occurs.

6. Dependency Management: Your Third-Party Code Is Your Third-Party Risk

Here’s a sobering fact: most modern JavaScript applications are 90% third-party code. Every library you import is a potential vulnerability.

The pattern: audit, update, and minimize.

• Audit regularly: Run npm audit to identify known vulnerabilities in your dependencies.
• Update frequently: Outdated libraries are a primary attack vector. Keep them current.
• Minimize: Only include what you actually need. Every extra dependency is an extra attack surface.

The mistake most developers make: Assuming that because a library is popular, it’s secure. Popularity doesn’t equal security. Vulnerable libraries have been found in some of the most widely used packages.

The pattern that works: Implement code obfuscation and minification to make it more difficult for attackers to read and understand your logic. Regularly audit third-party libraries to ensure your application doesn’t rely on vulnerable dependencies.

7. Avoid Dangerous Functions: The “Just Don’t Do It” Pattern

Some JavaScript functions are like loaded guns. They’re useful in specific situations, but they’re also the easiest way to shoot yourself in the foot.

The pattern: avoid eval(), new Function(), and other code evaluation tools. Use textContent or innerText for DOM updates instead of innerHTML.

Why these functions are dangerous: They execute arbitrary code. If an attacker can control any part of the string passed to these functions, they can execute malicious code in your users’ browsers.

The mistake most developers make: Using innerHTML for convenience. It's faster to type, but it's also faster to exploit.

The pattern that works: Untrusted data should only be treated as displayable text. Never treat untrusted data as code or markup within JavaScript code. Always encode and delimit untrusted data as quoted strings when entering the application.

The Compound Effect

Here’s what I’ve learned after implementing these seven patterns: security isn’t about perfection. It’s about layers.

Each pattern protects against specific attack vectors. CSP stops malicious scripts from executing. Input validation and sanitization prevent injection. Trusted Types enforces sanitization at the API level. CSRF protection prevents unauthorized actions. Secure cookies protect sessions. Dependency management reduces third-party risk. Avoiding dangerous functions eliminates common vulnerabilities.

No single pattern is foolproof. But together, they create a defense-in-depth that makes your application significantly harder to exploit.

The Mindset Shift

The biggest change wasn’t technical. It was mental.

I stopped treating security as something I’d “get to later.” I started treating it as a fundamental part of how I build software. Every feature I write, I ask: “How could this be exploited?” Every library I import, I ask: “What’s the risk here?”

It’s not paranoia. It’s professionalism.

Your Turn

Start with one pattern today. Probably the easiest is secure cookies — it’s a configuration change, not a code rewrite. Then add CSP. Then input validation. Then the rest.

You don’t need to implement all seven overnight. But each one you add makes your application more secure, and more importantly, makes you a better developer.

Because the best security is the kind you never have to think about — because it’s built into how you work.

P.S. — The next time you’re tempted to use innerHTML because it's faster, remember: convenience is expensive when it costs you your users' trust. Build it right from the start.

Before you go

• Please take a moment to like the post and follow the writer!
• Did you know that over 400,000 developers share what they’re building, learning, and discovering across our platforms every month? Learn how you can contribute here