HTTP security policy
Every webhost24.in response carries the rules below. The marketing site and the customer control panel both honour the same policy, and we ship the same policy to staging, preview, and production so the contract is identical end-to-end.
The short version
We use a default-deny Content-Security-Policy, force TLS for one year with the HSTS preload list, refuse framing from any site, isolate cross-origin browsing contexts, and disable every browser feature the marketing site does not need. The combination is the OWASP Secure Headers Project recommended baseline plus a few modern additions. Every header below is set by the Astro middleware on the edge - there is no per-page opt-in required and no per-route opt-out. If you find a surface where one of these headers breaks a legitimate use case, that is a bug; file it 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://www.googletagmanager.com https://www.google-analytics.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: https://www.googletagmanager.com https://www.google-analytics.com https://*.tile.openstreetmap.org; 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-requestsRestrict sources for scripts, styles, images, fonts, frames, and connections. Allows GA4, Google Fonts, OpenStreetMap tiles, and YouTube embeds. No unsafe-eval. No external scripts except GA4. Upgrades insecure requests.
The Content-Security-Policy header is the single most important defense against cross-site scripting and supply-chain injection. We use a default-deny posture: everything is 'self' unless explicitly allowed. The 'unsafe-inline' on script-src + style-src is a deliberate concession for our marketing site's inline JSON-LD blocks and Tailwind's critical CSS path; unsafe-eval is forbidden so a compromised dependency cannot execute dynamic code. The img-src + font-src allow-lists cover GA4 measurement pixels, Google Fonts, and the OpenStreetMap tile servers we render on /contact. The frame-ancestors directive is the modern replacement for X-Frame-Options; together with form-action 'self' it stops clickjacking on the marketing site + the customer control panel.
Strict-Transport-Security
max-age=31536000; includeSubDomains; preloadForce TLS for 1 year + all subdomains. Preload-eligible (we are in the Chrome HSTS preload list).
Strict-Transport-Security tells every browser that visits webhost24.in: 'never speak HTTP to me, ever.' The max-age of one year means the rule survives browser restarts and OS reinstalls. includeSubDomains makes the rule apply to the marketing site, the docs subdomain, the customer control panel, and the API surface in a single declaration. The preload directive submits our domain to the Chrome HSTS preload list, which hard-codes the rule into the browser itself before any request leaves the machine. We are listed. The downgrade attack surface for our visitors is effectively zero.
X-Frame-Options
DENYRefuse to be framed by any site. Prevents clickjacking on the marketing site + the customer control panel.
X-Frame-Options DENY is a belt-and-braces companion to the CSP frame-ancestors directive. Even if a future CSP regression allowed a same-origin embed, this header would still refuse the frame. The WebHost24 surfaces never need to be rendered inside another site; if you find a screen that needs iframe embedding (for example, a partner dashboard widget), file an issue and we will scope a controlled exception. Today the default is the safest possible.
X-Content-Type-Options
nosniffTell browsers not to MIME-sniff responses. Blocks content-type confusion attacks.
Without nosniff, an attacker who can upload a polyglot file (one that parses as both a PNG and a JavaScript payload) might trick a browser into running the file as script. The nosniff value tells the browser to trust the Content-Type header and refuse to guess. The cost is zero - we serve every static file with the correct Content-Type from the build pipeline - so the safety benefit is free.
Referrer-Policy
strict-origin-when-cross-originSend full Referer on same-origin requests, only the origin on cross-origin. Default since Chrome 85.
The Referer header leaks the URL you came from to the URL you visit next. If you click a link from your billing dashboard to your bank, you do not want the bank to see the page path inside of the dashboard. strict-origin-when-cross-origin ships the full URL to same-origin links and only the bare origin (scheme + host + port) on cross-origin links. This is the default policy in modern browsers; we declare it explicitly so older browsers, intermediaries, and any custom client code cannot widen it.
Permissions-Policy
camera=(), microphone=(), geolocation=()Disable all sensitive APIs by default. The marketing site uses none of them.
Permissions-Policy is the modern replacement for Feature-Policy. It declares which browser features are allowed for the document and any embedded frames. Our marketing site does not need camera, microphone, geolocation, USB, serial, or any other sensitive API; we explicitly deny each one with an empty allowlist (). If a future feature genuinely needs an exception (for example, a webcam QR-code scanner on the support form), we will scope it to the exact iframe that needs it rather than enable it globally.
Cross-Origin-Opener-Policy
same-originIsolate browsing context from cross-origin windows. Protects against side-channel attacks.
Cross-Origin-Opener-Policy: same-origin declares that any window we open (window.open) and any window that opens us must share our origin. This breaks the link between the two browsing contexts at the browser level, which blocks side-channel attacks like Spectre variants that rely on a cross-origin opener relationship. The customer control panel benefits the most: a malicious site that managed to open a control-panel tab in a popup cannot read memory from the popup once the user navigates away.
Cross-Origin-Embedder-Policy
require-corpRequire cross-origin resources to explicitly grant permission. Prevents accidental data leakage via embedded resources.
Cross-Origin-Embedder-Policy: require-corp works alongside COOP to enable cross-origin isolation. Any resource we embed (images, scripts, fonts, iframes) must declare itself either same-origin or cross-origin with an explicit Cross-Origin-Resource-Policy header granting us permission. Resources that fail to declare are blocked. The configuration is incompatible with the analytics cookies we ship, so the analytics iframe must use the credentialless flag - we test the full chain on every release.
Cross-Origin-Resource-Policy
same-originBlock other origins from embedding our resources. Strongest setting for a self-contained marketing site.
Cross-Origin-Resource-Policy: same-origin is the strictest setting. Any browser that tries to load a WebHost24 asset (image, script, stylesheet, font, video) from a third-party origin is refused. The same-origin value is right for us because the WebHost24 site is self-contained - we do not serve assets that need to be embedded on partner pages. If we ever publish a white-label widget or an embeddable badge, we will scope a per-asset Cross-Origin-Resource-Policy: cross-origin declaration for that specific path.
Review + disclosure
How this policy is maintained
Review cadence
The policy is reviewed on every release. The middleware that emits these headers lives in a single file under src/middleware.ts; any change to the header values requires a code review and a deploy. We run the OWASP ZAP baseline scan against the marketing site before every release; the scan report is internal but the test threshold is documented on the security disclosure page.
Coordinated disclosure
If you find a way to bypass any of these headers, or any other security issue on a WebHost24 surface, please disclose it via the security disclosure channel. We acknowledge every report inside one Indian business day and triage the issue against the same SLA our paying customers receive. See /security/disclosurefor the PGP key and the responsible-disclosure timeline.