Why Do We Need Security Headers?

Listen to the full episode above or read the article below:

Jacek Marmuszewski dropped some knowledge bombs in his insightful talk, "Why Did We Need Security Headers?" at Devoxx Poland 2023. In this session, Jacek delved into the crucial role security headers play in protecting web applications from various threats.

"My backend is super secure, so I don't need to worry about frontend security." - I've heard this line from frontend developers countless times. Here's what they miss: the security landscape fundamentally changed when we moved from server-rendered applications to single-page apps.

We're now packing the code and sending it out to the user. We've moved a lot of functionality to users' environments—environments we don't control. We don't control if applications or browsers are up to date, we don't control what users do underneath, and we build really rich APIs just to give them access to data stored in our secure environment.

Yet we're still using security approaches designed for the 1990s.

The Uncomfortable Truth About Modern Web Applications

Think about the traditional web application model. Your backend renders HTML, ships it to the user, and maintains control. All your security measures—firewalls, WAFs, authentication layers—sit safely in your data center.

Now think about modern SPAs. You're packaging your entire application and sending it to users' browsers. Your secure perimeter? It just expanded to include every device your users own.

The challenge is real. There was an article in one of the Polish blogs about a huge leak from Polish services. When you read through it, the leak was actually related to malware that users were installing. But the article headline blamed the services, not the users running outdated systems.

Your reputation is on the line, regardless of where the vulnerability actually sits.

Six Real Attacks That Work Today

As a DevSecOps engineer who's worked on countless security audits, I've seen these attacks succeed against production applications. Let me walk you through them—and more importantly, how to prevent them.

Day 1: The Cross-Origin Attack That Still Works (Sometimes)

Ten years ago, I could create a website called Fluffy.com (yes, that's my example evil site for this presentation), embed some JavaScript, and read your session data from another site when you visited my page.

The concept: create a page that sends a GET request to another domain (like facebook.com or any API), add credentials to include cookies, and send the request.

Why it worked: Ten years ago, if you didn't have CORS headers, the assumption was that anyone could read your content. Browsers automatically include cookies in cross-origin requests, and any site could read the response.

Modern fix: CORS (Cross-Origin Resource Sharing) headers block this by default in modern browsers. But here's the catch—many corporate systems still ask you to disable browser security because they don't know how to configure CORS properly.

The mitigation:

Never use * with credentials. While RFC says it's valid, browsers treat it as a misconfiguration and block everything.

Day 2: The Invisible Click That Steals Your Actions

Remember when Google Drive introduced drag-and-drop file sharing? Attackers immediately built games where fruits fell from the top of the screen, and you had to drag them into baskets.

Except that the "game" was a transparent overlay. Users were actually dragging their private files from Google Drive into the attackers' drives.

This attack still works and it's called clickjacking.

The mitigation:

Or for more control:

This prevents your application from being embedded in iframes. Most SPAs don't need iframe embedding anyway—so just block it.

Day 3: The MIME Type Confusion Attack

Here's something that catches even experienced developers: browsers have built-in AI that tries to detect file types, overriding your MIME type declarations.

I've seen attackers upload "images" that were actually JavaScript. The server stored them as images, the threat detection system scanned them as images, but browsers executed them as JavaScript.

The mitigation:

This tells browsers to trust your MIME types and stop trying to be clever.

Day 4: Script Injection Through URL Parameters

Single-page applications love putting data in URLs—it makes deep linking work beautifully. But without proper sanitization, those URLs become injection vectors.

The scary part? These attacks never touch your backend. I can download your SPA, turn off my internet, and spend hours finding injection points. You'll never know I'm testing your application.

The mitigation:

Content Security Policy (CSP) is your most powerful tool:

Content-Security-Policy: 
  default-src 'self'; 
  script-src 'self' 'sha256-[your-script-hash]

CSP does three critical things:

1. Specifies exactly which sources can load JavaScript

2. Blocks inline JavaScript entirely

3. Reports attempts to violate your server

Pro tip: Enable CSP in report-only mode first. You'll discover all the third-party scripts you forgot about. Once reports stop coming, switch to enforce mode.

Day 5: The Referrer Header Information Leak

Want passive income as a hacker? Host a popular JavaScript library. Every time someone uses it, you'll see their full URLs in your referrer logs—complete with password reset tokens, magic login links, and admin panel paths.

I've seen production applications leak:

• Authentication tokens in query parameters

• Internal API endpoints

• User identification data

• Application structure

The mitigation:

Or for less aggressive blocking:

Honestly, I've never found a legitimate use case that requires the referrer header. Just disable it.

Day 6: The WiFi Pineapple in Your Conference Room

This is where it gets physical. For about $120, anyone can buy a WiFi Pineapple—a device specifically designed for man-in-the-middle attacks.

How it works:

1. The device broadcasts a stronger signal than your legitimate WiFi

2. Your devices automatically connect to the stronger signal

3. Attacker sees all your unencrypted traffic

I actually brought one to conferences (powered off, for demonstration purposes only). If your application doesn't enforce HTTPS, every password and session token travels in plaintext.

The mitigation:

HSTS (HTTP Strict Transport Security) tells browsers to never make unencrypted requests to your domain. Even if users type http://, browsers upgrade to https:// automatically.

Advanced option:

Public Key Pinning prevents attackers from using stolen or fraudulently issued certificates. Only use this if you're handling banking or healthcare data—it's complex to maintain.

The Security Headers Checklist for Modern SPAs

Here's what every single-page application should implement today:

Essential (implement immediately):

• CORS configuration: Access-Control-Allow-Origin

• Frame blocking: X-Frame-Options: DENY

• MIME type enforcement: X-Content-Type-Options: nosniff

• HTTPS enforcement: Strict-Transport-Security

• Referrer policy: Referrer-Policy: no-referrer

Critical (implement this quarter):

• Content Security Policy with reporting

• CSP migration from report-only to enforce mode

Advanced (for high-security applications):

• Public Key Pinning for certificate validation

Why This Matters More Than You Think

The internet is younger than you think. HTTP/1.0 was standardized in 1996. SSL 1.0 was introduced in 1994 and had security flaws you could exploit with pen and paper in minutes—literally with a calculator on your phone. Early Unix servers never asked for passwords—you just told them who you were, and if you typed "I'm Groot," you were an admin.

We're still living with this technical debt.

Internet Explorer 6 died in 2014. That's when security in browsers actually started to kick in. The concepts we take for granted today didn't exist when many applications were designed.

Modern frameworks and tools make it easy to set security headers. There's no excuse for not using them.

The Bottom Line

Security headers are a way to extend the premise of a secure space from your data centers to users' browsers. They instrument browsers to work with the same security policies and principles you have internally.

The attacks I showed you work in production today—some require specific browser configurations, but they're real. The mitigations are straightforward configuration changes.

The weakest link in your security chain? It might be the frontend you're not securing.

About the presentation: This article is based on "Why Do We Need Security Headers?" presented by Jacek Marmuszewski at Devoxx Poland 2023. Jacek is the co-founder of Let's Go DevOps, where he helps companies build secure cloud infrastructure.

Want to learn more about securing your infrastructure? Contact: contact@letsgodevops.pl