HTTP security policy

Each webhost24.in response carries the rules below. The marketing site and the customer control panel both follow the same rules. We ship them to staging, preview, and production too. So the promise is the same everywhere.

The short version

We use a default-deny Content-Security-Policy. We force TLS for one year with the HSTS preload list. We refuse framing from any site. We keep cross-origin browsing contexts apart. We turn off each browser feature our site does not need. Together this is the OWASP Secure Headers Project baseline, plus a few newer rules. Every header below is set in one file at the edge. No page has to opt in, and no page can opt out. If one of these headers breaks a good use case, that is a bug on our side. Tell us on the security disclosure channel.

Per-header documentation

Each rule, with the why

The exact header value, the one-line purpose, and a paragraph-length explainer for security reviewers, procurement teams, and curious customers.

Content-Security-Policy

default-src 'self'; script-src 'self' 'unsafe-inline' https://analytics.webgrow24.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: https://analytics.webgrow24.com; font-src 'self' https://fonts.gstatic.com; frame-src 'self' https://www.youtube.com https://www.youtube-nocookie.com; frame-ancestors 'none'; base-uri 'self'; form-action 'self'; object-src 'none'; worker-src 'self'; upgrade-insecure-requests

We lock down where scripts, styles, images, fonts, frames, and links may come from. We allow our own analytics server, Google Fonts, and YouTube embeds. We block unsafe-eval. We allow no outside scripts except the analytics tracker. We upgrade any insecure request.

This header does the most work of any of them. It stops cross-site scripting and attacks that come through a bad package. We deny all by default. A source has to be on our list before a browser may use it. We allow unsafe-inline for scripts and styles, because our site runs JSON-LD blocks and critical CSS inline. We never allow unsafe-eval, so a bad dependency cannot run its own code. Our img-src and font-src lists cover our analytics server and Google Fonts. The frame-ancestors rule replaces X-Frame-Options. With form-action 'self' it stops clickjacking on our site and on the customer control panel.

Strict-Transport-Security

max-age=31536000; includeSubDomains; preload

We force TLS for 1 year and for all subdomains. The Chrome HSTS preload list has us on it.

This header tells each browser that visits webhost24.in: never speak plain HTTP to us. The max-age of one year means the rule survives a browser restart or a new machine. includeSubDomains extends the rule to our site, the docs subdomain, the customer control panel, and the API. The preload directive puts our domain on the Chrome HSTS preload list, which bakes the rule into the browser before any request leaves the machine. We are on that list. Our visitors have no way to downgrade.

X-Frame-Options

DENY

We refuse to sit in a frame on any site. It stops clickjacking on our site and on the customer control panel.

This header is a second lock on the same door as frame-ancestors. Even if a future change to our CSP let a page sit in a frame, this header still says no. We never need our pages inside another site. If you need a screen in an iframe, for a partner widget, tell us and we will look at a safe way to do it. Today the default is the safest one we can set.

X-Content-Type-Options

nosniff

We tell browsers not to guess the type of a file. It blocks attacks that confuse a file type.

Without nosniff, a file that looks like a PNG but holds script code could trick a browser into running it. This header tells the browser to trust the Content-Type we send and not to guess. It costs nothing, because we send the right type for each file. So the safety is free.

Referrer-Policy

strict-origin-when-cross-origin

We send the full Referer on same-origin requests, and only the origin on other sites. Chrome has done this since version 85.

The Referer header tells the next site where you came from. If you click from your billing dashboard to your bank, the bank should not see the page path inside the dashboard. strict-origin-when-cross-origin sends the full URL to sites on the same origin. For other sites it sends only the origin, which is the scheme, the host, and the port. Modern browsers do this by default. We set it out so old browsers and any custom client code cannot widen it.

Permissions-Policy

camera=(), microphone=(), geolocation=()

We turn off each sensitive browser feature by default. Our site uses none of them.

Permissions-Policy is the new name for Feature-Policy. It says which browser features a page may use, in the page and in any frame it holds. Our site needs no camera, microphone, geolocation, USB, or other sensitive feature. We deny each one with an empty list. If we ever need one, for a webcam QR code scanner on the support form, we will allow it for that one frame only.

Cross-Origin-Opener-Policy

same-origin

We keep our browsing context apart from windows on other sites. It helps against side-channel attacks.

Cross-Origin-Opener-Policy: same-origin says that any window we open, and any window that opens us, must share our origin. That link is cut at the browser level, which blocks side-channel attacks such as Spectre variants. The customer control panel gains the most. If a bad site opens a control panel tab in a pop-up, it cannot read the memory of that tab once the user moves away.

Cross-Origin-Embedder-Policy

require-corp

We ask other sites for permission before they load our files. It stops data leaks through loaded content.

Cross-Origin-Embedder-Policy: require-corp works with COOP to give us cross-origin isolation. Every resource we hold, such as images, scripts, fonts, and frames, must say it is ours, or say that it is cross-origin and allow us. Anything that does not say is blocked. This setup does not work with the analytics cookies we ship, so the analytics frame must use the credentialless flag. We test the whole chain on each release.

Cross-Origin-Resource-Policy

same-origin

We stop other sites from embedding our files. It is the strictest setting for a site that stands alone.

Cross-Origin-Resource-Policy: same-origin is the strictest setting. A browser that tries to load a WebHost24 asset, such as an image, script, stylesheet, font, or video, from another site is refused. That is right for us, because our site stands alone. We do not serve assets that a partner page needs to embed. If we ever ship a white-label widget or an embeddable badge, we will set a cross-origin rule for that one path.

Review + disclosure

How this policy is maintained

Review cadence

We look at this policy on each release. The code that sets these headers lives in one file under src/middleware.ts. Any change to a header value needs a code review and a deploy. We run the OWASP ZAP baseline scan on our site before each release. The report is internal, but the test bar is written down on the security disclosure page.

Coordinated disclosure

If you find a way to get past any of these headers, or any other security issue on a WebHost24 site, please tell us on the security disclosure channel. We reply to each report within one Indian business day. We check the issue against the same bar our paying customers get. See /security/disclosure for the PGP key and the timeline we promise.