All articles · Compliance & due diligence

Security headers for grant management software websites

The browser security headers a grant management software site should ship before launch, and how to think about content security policy, framing, referrers and embedded forms.

23 June 2026The Grantledger team2 min read

Security headers are not a complete security programme, but they are a useful launch gate. They tell browsers how to treat the site and reduce classes of avoidable risk.

For grant management software, they matter because the public site often sits next to more sensitive surfaces: funder consoles, applicant forms, grantee reports and public award dashboards.

Content Security Policy

A content security policy should start restrictive and add only what the site actually needs. For a marketing site, a sensible baseline is:

  • scripts from the site itself and approved analytics providers;
  • images from the site, data URLs for small inline assets, and approved analytics pixels;
  • fonts from the site;
  • form submissions back to the site;
  • no object embeds;
  • no framing unless an explicit embed route is being used.

Inline scripts and styles are common in modern frameworks and analytics snippets, but every exception should be deliberate.

Frame controls

Most pages should not be framed. Use frame-ancestors 'none' and X-Frame-Options: DENY for the default site.

Embedded applicant forms are different. They may need to appear on a funder's own domain, but that should be an explicit allow-list, not frame-ancestors *. A launch site can keep embeds denied by default and enable customer domains later.

HSTS and transport

Strict-Transport-Security tells browsers to use HTTPS. Once the live domain is stable and serving HTTPS correctly, use a long max-age and include subdomains. Preload only when you are confident every subdomain should be HTTPS-only.

Referrers and permissions

Referrer-Policy: strict-origin-when-cross-origin keeps enough attribution for normal analytics while reducing leakage of full paths to other origins.

Permissions-Policy should disable browser capabilities the product does not need. A grant application form normally does not need camera, microphone, geolocation or payment browser APIs.

Verify headers on every route family

Do not only check the homepage. Check:

  • the homepage;
  • blog articles;
  • security and privacy pages;
  • removed pages such as old pricing URLs;
  • private console redirects;
  • tokenized public applicant/report routes;
  • embed routes.

The exact policy can vary by route family, but the variation should be intentional and documented.

Share