top of page
  • Linkedin

HTTP Security Headers: Your Practical Guide to Safer Web Apps (Part 1)

  • Writer: Avinash Ghadshi
    Avinash Ghadshi
  • Jul 7
  • 5 min read

Updated: Aug 23

HTTP Security Headers are server response headers that instruct browsers on how to handle your web application's content securely. They mitigate attacks like XSS, click-jacking, and MIME-type sniffing, adding an essential layer of defense.


In this practical guide, you’ll learn what HTTP Security Headers are, how they work under the hood, and how to implement them with actionable code snippets for your server stack. Let’s start making your web apps safer, one header at a time.


What Are HTTP Security Headers?

They are additional HTTP headers set by your server to:

  • Enforce HTTPS

  • Prevent code injection

  • Restrict framing

  • Control referrer data

  • Limit browser features

They do not replace secure coding but strengthen your site's defense.


Types of Security Headers

Types of HTTP Security Headers
Types of HTTP Security Headers

Transport Security Headers

Content Security Headers

Privacy and Referrer Control Headers

Feature and Permissions Control Headers

Cross-Origin Isolation and Resource Policy Headers

Other Useful Security Headers

In this post, we’ll focus on three essential HTTP security headers you can implement today to strengthen your web applications. The remaining advanced headers will be covered in Part 2 of this series.

Let’s dive in and understand them one by one.


Strict-Transport-Security (HSTS):

Forces browsers to use HTTPS only for a specified period. It prevents SSL Striping attacks.


Example

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

  • max-age=63072000 enforces HTTPS for 1 year

  • includeSubDomains ensures all subdomains follow HTTP.

  • preload allows inclusion in browser preload lists (browsers know to only use HTTPS even before the first visit).


How it works:

Working of HSTS
HSTS Working

  • First Visit (via HTTPS):The server sends:

  • Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

  • Browser stores the rule:For max-age seconds (e.g., 1 year), the browser remembers to always use HTTPS for this domain (and subdomains if specified).

  • Browser store this locally but not accessible via javascript.

  • This settings getsCleared if the user clears “Site Settings” or “All browsing data” (but not always with normal cache clearing)

  • Next Visit (HTTP):Even if the user types http://codingcipher.com, the browser checks this HSTS cache before making the request, upgrading it internally to https://codingcipher.com if a rule exists.

  • Blocks users from accepting invalid SSL certificates on your domain, reducing MITM risks.


Content-Security-Policy (CSP)

Prevents XSS and data injection by whitelisting allowed content sources.


Example:

Content-Security-Policy: default-src 'self'; img-src *; script-src 'self' https://trusted.cdn.com; object-src 'none';


Content-Security-Policy Directives Cheat Table

Content Security Policy Cheat sheet
Content Security Policy Directives

CSP Common Source Values

Common Values for CSP Header
CSP Common Source Values

How it Works:

Working of CSP
CSP Working

  • Server sends CSP header with HTTP response:

  • Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.com;

  • Browser reads the policy before rendering the page.

  • When the page tries to load a resource (JS, CSS, image, frame):

  • Browser checks if the resource’s URL matches the CSP rules.

    • If allowed ➔ resource loads.

    • If blocked ➔ browser blocks it and logs a CSP violation.

X-Content-Type-Options

Prevents MIME type sniffing to avoid executing files as a different type.

Example: X-Content-Type-Options: nosniff nosniff tells the browser not to guess (MIME sniff) the content type; it enforces using the Content-Type declared by the server.


How it works:

Working of X-Content-Type-Options
X-Content-Type-Options Working

  • Server sends:

  • Content-Type: text/plain X-Content-Type-Options: nosniff

  • Browser downloads the resource and checks:

  • Is nosniff present?

    Yes: Do not sniff, use declared Content-Type strictly.

    No: Browser may inspect file content and reassign MIME type if it thinks it’s different.

  • Result:

    If nosniff is set and Content-Type: text/plain, a JS file served as text/plain will not execute in the browser.

  • If nosniff is not set, the browser might interpret the file as JavaScript and execute it even if it was uploaded as text/plain.


X-Frame-Options

Prevents your site from being embedded in frames/iframes, blocking click-jacking attacks.


Example X-Frame-Options: DENY


Options:

  • DENY – never allow framing.

  • SAMEORIGIN – allow only from the same origin.

  • ALLOW-FROM https://codingcipher.com – allow specific origin (less supported).

How it works:

Working of X-Frame-Options
X-Frame-Options Working

  • Server sends header:

  • Browser receives the page.

  • Another site tries to embed your page in an iframe.

  • Browser checks:

    • If DENY: Never allow framing.

    • If SAMEORIGIN: Allow framing only if the framing page is from the same origin.

    • If ALLOW-FROM uri: Allow framing only from the specified URI (note: deprecated, limited support).

  • If framing is disallowed:

    Browser blocks rendering inside the frame, showing a blank frame or error.


X-XSS-Protection (legacy)

Enables or disables browser’s built-in XSS filter (deprecated in modern browsers).

Referrer-Policy

Controls how much referrer information is sent with requests to other sites.

Example:

Referrer-Policy: strict-origin-when-cross-origin


Options:

no-referrer

When no-referrer header sent with requests; target site gets no info about where the request came from.

Example:

  • Page A ➔ Page B: no-referrer header sent.

strict-origin

Send only the origin (scheme + host + port) as referrer, but only for HTTPS ➔ HTTPS.

Effect:


strict-origin-when-cross-origin

Sends Full URL on same-origin; origin on cross-origin, but only for HTTPS ➔ HTTPS.


Effect:

same-origin

Send full referrer URL only for same-origin requests.


Effect:

How it works?

Working of Referrer-policy
Referrer-Policy Working

  • Server sets header:

  • Referrer-Policy: strict-origin-when-cross-origin

    or in HTML:

  • <meta name="referrer" content="strict-origin-when-cross-origin">

  • User visits https://siteA.com/page1.

  • User clicks a link or loads a resource to:

  • Browser checks:

    • What is the configured policy?

    • Is the request same-origin or cross-origin?

    • Is there a protocol downgrade?

  • Browser sends the appropriate Referrer header:

    Depending on the policy:

    • no-referrer ➔

      • Sends nothing.

    • strict-origin ➔

      • Sends origin only if HTTPS ➔ HTTPS, else nothing.

    • strict-origin-when-cross-origin ➔

      • Sends full URL on same-origin.

      • Sends origin on cross-origin HTTPS ➔ HTTPS.

      • Sends nothing on HTTPS ➔ HTTP.

      • Sends full URL on same-origin.

    • same-origin ➔

      • Sends full URL on same-origin.

      • Sends nothing on cross-origin.


In this part, we explored three essential HTTP security headers you can implement today to strengthen your web apps:


Strict-Transport-Security (HSTS) to enforce HTTPS.

Content-Security-Policy (CSP) to control what content loads on your site.

Referrer-Policy to protect user privacy during navigation.


These headers form the core of your app’s security posture, helping you reduce attack surfaces, prevent data leaks, and build user trust.


What’s Next?

In Part 2, we will explore advanced and modern security headers including:


Feature and permissions control with Permissions-Policy

Cross-origin isolation using COOP, COEP, and CORP

Cache-Control for hardening sensitive data


These will help you move from foundational security to advanced protection in your web applications.

Comments

bottom of page