DEV Community: head_of_david

Security Headers Checklist: 6 HTTP Headers Every Site Should Send

head_of_david — Tue, 03 Nov 2026 14:00:00 +0000

Security headers are the cheapest hardening you'll ever ship: a few lines of server config, no code changes, and whole classes of attack — clickjacking, MIME sniffing, protocol downgrades, much of XSS — get harder or impossible. Here are the six worth sending on every site, in the order that's safest to roll them out.

The checklist

Header	Recommended value	Stops
X-Content-Type-Options	`nosniff`	Files being run as a type they weren't served as
Referrer-Policy	`strict-origin-when-cross-origin`	Full URLs leaking to other sites
X-Frame-Options	`DENY` (or CSP `frame-ancestors 'none'`)	Clickjacking via iframes
Permissions-Policy	`camera=(), microphone=(), geolocation=()`	Injected code asking for powerful features
Strict-Transport-Security	`max-age=31536000; includeSubDomains`	HTTPS → HTTP downgrades
Content-Security-Policy	depends on your site — start in report-only mode	Most XSS

The first four are nearly risk-free: they rarely break anything. HSTS and CSP need care, so they come last. To build all six at once for your server or host, use the security headers generator.

1–4: the safe ones

X-Content-Type-Options: nosniff makes browsers trust your Content-Type instead of guessing. The only thing it can break is a script or stylesheet served with the wrong type, which you want to fix anyway.

Referrer-Policy: strict-origin-when-cross-origin is already the default in current browsers; sending it makes the behaviour explicit for older ones. Use no-referrer or same-origin if your URLs carry anything sensitive.

X-Frame-Options: DENY stops other sites from loading your pages in an iframe. Use SAMEORIGIN if you frame your own pages. Once you have a CSP, its frame-ancestors directive does the same job and is the modern replacement — send both for older browsers.

Permissions-Policy switches off browser features you don't use. List the ones that matter — camera, microphone, geolocation, payment — with an empty allowlist ().

5: HSTS, carefully

Strict-Transport-Security tells browsers to use HTTPS for your domain, every time, for max-age seconds — even if someone types http://. It's powerful precisely because it can't be undone quickly: if a subdomain doesn't support HTTPS and you've sent includeSubDomains, browsers will refuse to load it until the max-age runs out.

Roll it out in steps:

max-age=300 — five minutes, to test.
max-age=86400; includeSubDomains — once you've confirmed every subdomain serves HTTPS.
max-age=31536000; includeSubDomains — a year, the usual production value.
Add preload and submit the domain to hstspreload.org only if you're sure; removal takes months.

6: CSP, in report-only mode first

A Content-Security-Policy tells the browser which sources may provide scripts, styles, images and frames. A good one turns most injected-script XSS into a blocked request. It's also the header most likely to break your site, so start with Content-Security-Policy-Report-Only: the browser reports violations to the console (and to an endpoint, if you configure one) without blocking anything.

A starting policy for a site that serves its own assets:

Content-Security-Policy: default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; frame-ancestors 'none'

Third-party scripts, analytics and inline <script> blocks all need explicit allowances — the CSP guide covers nonces, hashes and the usual breakages.

Setting them

Next.js (next.config.js):

const securityHeaders = [
  { key: "X-Content-Type-Options", value: "nosniff" },
  { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
  { key: "X-Frame-Options", value: "DENY" },
  { key: "Permissions-Policy", value: "camera=(), microphone=(), geolocation=()" },
  { key: "Strict-Transport-Security", value: "max-age=31536000; includeSubDomains" },
];

module.exports = {
  async headers() {
    return [{ source: "/(.*)", headers: securityHeaders }];
  },
};

nginx (inside the HTTPS server block — always adds them to error pages too):

add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header X-Frame-Options "DENY" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

One nginx trap: add_header directives are inherited only if the inner block defines none of its own. A single add_header inside a location silently drops every header set at the server level for that location.

Express: the Helmet middleware sets sensible defaults for all of these, including a starter CSP — app.use(helmet()).

Vercel (vercel.json) and Netlify (_headers):

{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [{ "key": "X-Content-Type-Options", "value": "nosniff" }]
    }
  ]
}

/*
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin

Headers you can drop

X-XSS-Protection — the browser XSS filters it controlled have been removed. Send 0 or nothing.
Public-Key-Pins (HPKP) — removed from browsers; it could lock users out of a site permanently.
Expect-CT — obsolete now that Certificate Transparency is enforced by default.
Feature-Policy — replaced by Permissions-Policy.

Check your work

curl -sI https://your-site.example | grep -iE "strict-transport|content-security|x-content-type|referrer-policy|permissions-policy|x-frame"

To check many URLs at once, paste them into the HTTP Status Checker. For every header's full set of values, see the HTTP headers reference.

Originally published at devkult.com. To build all six for your server or host in one go, use the free Security Headers Generator.

CORS Errors Explained: How to Fix "No 'Access-Control-Allow-Origin' Header"

head_of_david — Tue, 27 Oct 2026 14:00:00 +0000

You call your API from the browser and the console fills with red: blocked by CORS policy. The confusing part is that the request usually did reach your server — often it even succeeded. CORS doesn't stop the request; it stops your JavaScript from reading the response. That's also why the same call works fine in curl or Postman: CORS is enforced by browsers, and only browsers.

What counts as cross-origin

An origin is the scheme, host and port together. These are all different origins:

https://app.example.com and https://api.example.com — different host
http://localhost:3000 and http://localhost:8080 — different port
http://example.com and https://example.com — different scheme

When a page on one origin fetches from another, the browser asks the server for permission through response headers, chiefly Access-Control-Allow-Origin.

Simple requests and preflights

Some requests are sent straight away, and the browser checks the response headers afterwards. Others trigger a preflight: an automatic OPTIONS request that asks whether the real request is allowed. A preflight happens when, among other things, the request:

uses a method other than GET, HEAD or POST,
sends a header outside a short safe list — Authorization is the classic one, or
sends Content-Type: application/json (only text/plain, multipart/form-data and application/x-www-form-urlencoded are exempt).

So almost every real API call — JSON body, bearer token — is preflighted. The server must answer that OPTIONS request successfully, with the right headers, before the browser sends the real one.

The common errors, and their fixes

"No 'Access-Control-Allow-Origin' header is present on the requested resource."
The response didn't include the header. Add it, with the calling origin as the value:

Access-Control-Allow-Origin: https://app.example.com
Vary: Origin

Vary: Origin matters when you choose the value per request: it stops a CDN from serving one origin's response to another.

"Response to preflight request doesn't pass access control check: It does not have HTTP ok status."
Your server answered the OPTIONS preflight with an error — often 401 because auth middleware ran first, or 404/405 because no route handles OPTIONS. Answer preflights before authentication, with 204 No Content and the CORS headers.

"Request header field authorization is not allowed by Access-Control-Allow-Headers in preflight response."
List every custom header the client sends:

Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Allow-Methods: GET, POST, PUT, DELETE

"The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'."
Requests that send cookies (credentials: "include") can't use *. Return the specific origin plus Access-Control-Allow-Credentials: true.

"Redirect is not allowed for a preflight request."
The preflight hit a redirect — commonly a trailing-slash or http→https rule. Call the final URL directly.

Server examples

Express, with the cors package and an explicit allow-list:

import cors from "cors";

app.use(cors({
  origin: ["https://app.example.com", "http://localhost:5173"],
  credentials: true,
  maxAge: 600, // cache the preflight for 10 minutes
}));

A Next.js route handler answers preflights by exporting OPTIONS:

const CORS = {
  "Access-Control-Allow-Origin": "https://app.example.com",
  "Access-Control-Allow-Methods": "GET, POST",
  "Access-Control-Allow-Headers": "Authorization, Content-Type",
};

export function OPTIONS() {
  return new Response(null, { status: 204, headers: CORS });
}

export async function POST(request: Request) {
  return Response.json({ ok: true }, { headers: CORS });
}

nginx in front of an API:

location /api/ {
  if ($request_method = OPTIONS) {
    add_header Access-Control-Allow-Origin "https://app.example.com" always;
    add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE" always;
    add_header Access-Control-Allow-Headers "Authorization, Content-Type" always;
    add_header Access-Control-Max-Age 600 always;
    return 204;
  }
  add_header Access-Control-Allow-Origin "https://app.example.com" always;
  proxy_pass http://127.0.0.1:3000;
}

The always flag makes nginx add the header to error responses too — without it, a 500 from your API shows up in the browser as a CORS error, which hides the real problem.

What not to do

Don't reflect any origin with credentials. Echoing whatever Origin arrives, together with Access-Control-Allow-Credentials: true, lets any website read your users' data with their cookies. Check origins against an allow-list.
Don't use mode: "no-cors". It makes the error disappear by giving you an opaque response you can't read. The request "works"; your code gets nothing.
Don't fight CORS in development. Use your dev server's proxy (Vite's server.proxy, Next.js rewrites) so the browser sees one origin.

Testing a preflight with curl

curl doesn't enforce CORS, but it can show you exactly what the browser would see:

curl -i -X OPTIONS https://api.example.com/items \
  -H "Origin: https://app.example.com" \
  -H "Access-Control-Request-Method: POST" \
  -H "Access-Control-Request-Headers: authorization, content-type"

Look for a 2xx status and the three Access-Control-Allow-* headers. To check what a list of endpoints returns, paste them into the HTTP Status Checker.

One last tip: a preflight is cached for as long as Access-Control-Max-Age says — up to 2 hours in Chrome and 24 hours in Firefox — so after changing CORS headers, test in a fresh private window.

For each header in detail, see the reference pages for Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, Access-Control-Allow-Credentials and Origin.

Originally published at devkult.com. For every CORS header in detail, see the HTTP headers reference.

ERR_TOO_MANY_REDIRECTS: How to Find and Fix a Redirect Loop

head_of_david — Tue, 20 Oct 2026 14:00:00 +0000

This page isn't working. example.com redirected you too many times. ERR_TOO_MANY_REDIRECTS

Firefox calls it "The page isn't redirecting properly". Both mean the same thing: the browser followed redirects until it hit its limit (20 in Chrome and Firefox), because two or more rules keep sending it back and forth. Something says "go to B", and B says "go to A".

Step 1: trace the loop

curl shows each hop without any browser cache in the way:

curl -sIL --max-redirs 10 http://example.com/ | grep -iE "^(HTTP|location)"

HTTP/1.1 301 Moved Permanently
location: https://example.com/
HTTP/2 301
location: http://example.com/
HTTP/1.1 301 Moved Permanently
location: https://example.com/

Now you can see the circle — here, HTTP → HTTPS → HTTP. The pattern in the location lines tells you which kind of loop you have. The HTTP Status Checker shows the same chain in the browser.

The usual causes

HTTPS redirect behind a proxy or CDN

The most common loop. Your app redirects HTTP to HTTPS, but it sits behind a load balancer or CDN that talks to it over plain HTTP. Every request arrives as HTTP, so the app redirects every request — forever.

Cloudflare: with SSL mode Flexible, Cloudflare connects to your server over HTTP. If the server redirects to HTTPS, you loop. Switch to Full (strict) and install a certificate on the origin.
Your app behind a proxy: tell the framework to trust the proxy's X-Forwarded-Proto header, so it knows the original request was HTTPS. In Express, app.set("trust proxy", 1); in Django, SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https"). See X-Forwarded-For for how the forwarded headers work.

www and apex rules fighting

One layer redirects www.example.com → example.com while another redirects example.com → www.example.com — often the hosting dashboard against an nginx or app rule. Pick one canonical host and make every layer agree.

Trailing-slash rules

A framework setting adds a trailing slash (/docs → /docs/) while the server or CDN removes it. Same fix: decide on one form and remove the other rule.

Login loops

A page requires authentication and redirects to /login; /login thinks you're logged in (or itself requires auth) and redirects back. Two common roots:

The session cookie is never stored — for example it's marked Secure but the site runs on plain HTTP, or its Domain doesn't match. See Set-Cookie.
The cookie isn't sent on the request that matters — a cross-site POST back from an identity provider, blocked by SameSite. See SameSite cookies explained.

CMS address settings

In WordPress, a mismatch between the "WordPress Address" and "Site Address" settings — http:// against https://, or www against no www — loops the same way. Make both identical and match your real canonical URL.

Step 2: rule out the browser's cache

A permanent redirect (301 or 308) can be cached by the browser indefinitely. After you fix the server, the browser may keep looping on its cached redirect. Test in a private window or with curl, and clear site data (DevTools → Application → Storage → Clear site data) for the real browser.

This is also why it's worth testing new redirects as 302 first — see 301 vs 302 vs 307 vs 308.

Quick checklist

Trace the hops with curl -sIL.
Find the two rules that disagree — protocol, host, slash or auth.
Keep one rule; remove or align the other.
Retest in a private window.

Originally published at devkult.com. To trace redirect chains for a list of URLs at once, try the free HTTP Status Checker.

Unexpected Token in JSON at Position 0: What It Means and How to Fix It

head_of_david — Fri, 16 Oct 2026 11:07:32 +0000

SyntaxError: Unexpected token '<', "<!DOCTYPE "... is not valid JSON

Older browsers and Node versions word it as Unexpected token < in JSON at position 0. Either way, the message is telling you something specific: the first character of what you tried to parse as JSON was < — and JSON never starts with <. You received HTML, not JSON. The parser is fine; the response isn't what you think it is.

The messages, decoded

Message	What you actually received
`Unexpected token '<', "<!DOCTYPE "...`	An HTML page — usually an error page, a login page or your app's `index.html`
`Unexpected end of JSON input`	An empty body
`"[object Object]" is not valid JSON`	An object you already parsed, passed to `JSON.parse` again
`"undefined" is not valid JSON`	The string `"undefined"` — often from `localStorage`
`Unexpected token ''` (an invisible character)	A UTF-8 byte order mark before the JSON
`Expected double-quoted property name`	A trailing comma, or single-quoted keys

Firefox says JSON.parse: unexpected character at line 1 column 1 of the JSON data, and Safari says JSON Parse error: Unrecognized token '<'. Python's equivalent is JSONDecodeError: Expecting value: line 1 column 1 (char 0), which requests raises from .json().

Step 1: look at what you got

Read the body as text before parsing it:

const res = await fetch("/api/items");
const text = await res.text();
console.log(res.status, res.headers.get("content-type"), text.slice(0, 200));

Or open DevTools → Network, click the request and look at the Response tab. Nine times out of ten, the answer is right there.

Step 2: match it to a cause

An HTML error page. The request hit a 404 or 500, and the server returned its HTML error page. Check the status code — response.json() doesn't care whether the request succeeded.

Your app's own index.html. Single-page apps return index.html for every unknown path, so a wrong API URL (/api/item instead of /api/items, or a missing /api prefix in production) gets HTML with status 200. Also check your dev server proxy: in development /api may be forwarded to the backend, but in production it isn't.

A login page. An expired session redirects to /login; fetch follows the redirect and hands you the login HTML. res.redirected will be true.

An empty body. 204 No Content responses and some error responses have no body, so there's nothing to parse — "Unexpected end of JSON input". Check the status before calling .json().

Parsing twice. response.json() and axios already return objects. Calling JSON.parse() on the result turns it into the string "[object Object]" first, which fails.

Not quite JSON. Hand-written JSON with trailing commas, comments, single quotes or NaN isn't valid. Paste it into the JSON validator to find the exact position.

Step 3: guard your fetch calls

Check the status and the Content-Type before parsing, and include the start of the body in the error so the next failure explains itself:

async function getJson(url, options) {
  const res = await fetch(url, options);
  const type = res.headers.get("content-type") ?? "";
  if (!res.ok || !type.includes("application/json")) {
    const body = await res.text();
    throw new Error(`${res.status} from ${url} (${type || "no content type"}): ${body.slice(0, 120)}`);
  }
  return res.json();
}

On the server side, make your API return JSON errors with Content-Type: application/json — including for 404s and 500s — so clients get a parseable message instead of an HTML page. The correct type for JSON is application/json.

The localStorage variant

JSON.parse(localStorage.getItem("settings")); // fine when the key exists

When the key doesn't exist, getItem returns null, and JSON.parse(null) happens to return null — no error. But if some code once saved localStorage.setItem("settings", undefined), the stored value is the string "undefined", which throws. Guard and reset:

function readSettings() {
  try {
    return JSON.parse(localStorage.getItem("settings")) ?? {};
  } catch {
    localStorage.removeItem("settings");
    return {};
  }
}

To inspect or tidy a JSON payload by hand, use the JSON formatter.

Originally published at devkult.com. When you need to find exactly where a payload breaks, paste it into the free JSON validator.