Security Headers

nsin can add response security headers to your site’s HTTPS traffic, off by default and set per domain — separate from the automatic Nsn-* proxy headers, which are always on.

Where to configure

1. Open your nsin dashboard and pick your domain.
2. Go to Security → Security Headers and toggle what you want.
3. HSTS is separate: Security → HSTS (below).

Changes apply within seconds. Turn any of them back off anytime.

Note

Security headers apply only to proxied, HTTPS responses. DNS-only records and plain http:// requests are never affected.

Available headers

Toggle	Header set	What it does
No MIME sniffing	X-Content-Type-Options: nosniff	Blocks content-type–confusion attacks by making browsers trust your origin’s exact Content-Type instead of guessing.
Referrer policy	Referrer-Policy: strict-origin-when-cross-origin	Trims the referrer sent to other sites to just your domain. Matches the modern browser default.
Strip fingerprint headers	removes X-Powered-By, X-AspNet-Version, X-AspNetMvc-Version, X-Generator, X-Drupal-Cache, X-Runtime	Removes headers that reveal your backend stack and version. Informational only — safe for virtually all sites.

Your origin always wins: nsin adds nosniff or Referrer-Policy only if your origin didn’t already send one. HTTPS only. Toggles are independent.

Caution

No MIME sniffing is the one toggle that can break a misconfigured site: if your origin serves assets with the wrong Content-Type (e.g. JavaScript or CSS as text/plain), a browser with nosniff refuses to load them. Only enable it once your origin sets correct content types. The other two toggles are safe for essentially all sites.

Enable headers one at a time and check a fresh tab before the next.

nsin does not set a Content-Security-Policy, CORS, or framing policy — only your app can make those calls. Set one on your origin and nsin passes it through, or write it at the edge with a header rule.

HSTS (HTTPS-only enforcement)

Strict-Transport-Security tells a browser to reach your domain over HTTPS only — after one visit it stops sending plain HTTP entirely. nsin already redirects HTTP to HTTPS at the edge for every proxied record, always; HSTS is the stronger, browser-side version.

Danger

HSTS cannot be fully undone. A browser that saw the header keeps refusing plain HTTP for the chosen duration, even after you turn HSTS off — that only stops new visitors from being pinned.

Enable it only once everything on the domain — every page, image, script, download, API path — works over HTTPS.

The duration ladder

The panel offers six durations and lets you move up one step per save:

Step	max-age	Cost of a mistake
5 minutes	300	Five minutes. This is where every domain starts.
1 hour	3600	An hour.
1 day	86400	A day.
1 week	604800	A week.
30 days	2592000	A month.
1 year	31536000	A year — and the value the preload list requires.

Give each step real traffic before the next. Lowering the duration is always allowed and is the first fix if something breaks — but it only helps returning visitors.

Other HSTS settings

• Include subdomains (includeSubDomains): extends the rule to every subdomain, including future and forgotten ones. Any not on HTTPS becomes unreachable to visitors who’ve seen the header — check them all first.

• Preload (preload): the prerequisite for submitting your domain to the HSTS preload list, shipped inside browsers, enforcing HTTPS from a visitor’s very first request. Requires HSTS on, subdomains included, a one-year duration, and typing your domain name to confirm. Setting the directive is step one only — submit at hstspreload.org yourself to get preloaded.

  Danger

  Preloading is effectively permanent. Coming off the list means asking hstspreload.org to delist you, then waiting months for browsers to update. Leaving nsin does not undo it either.

• How nsin sends it: the HSTS value replaces any Strict-Transport-Security your origin sends — a browser only reads the first one, and an origin quietly sending a year would defeat your ladder. Leave HSTS off and your origin’s own header passes through untouched.

Minimum TLS version

Under SSL/TLS you can set the oldest TLS version visitors may connect with:

Setting	Who can connect
TLS 1.2 (default)	TLS 1.2 and TLS 1.3. Everything in current use.
TLS 1.3 only	TLS 1.3 only. Older Android phones, Windows 7 machines, some corporate proxies and older API clients cannot connect at all.

Nothing below TLS 1.2 is accepted on any nsin domain — no weaker option exists. It’s enforced during the TLS handshake: a client below your minimum gets a connection error, not an explainable page. Before requiring 1.3, check real TLS 1.2 usage on the SSL/TLS page’s TLS breakdown. Unlike HSTS, this takes effect — and is undone — within seconds. HTTP/3 always uses TLS 1.3, so it’s unaffected.

See also Proxy Headers for the headers nsin adds automatically.