Security best practice

This page gives the order of work to harden a site or application on Quant, and the reason for each step. It applies to QuantCDN and QuantGov. Use it as a checklist for a new project, a security review, or a questionnaire from your security team.

Checklist

1. Serve static first, and proxy only the paths that need an application.
2. Lock the origin to Quant, so it accepts only requests through your Quant project.
3. Turn on the WAF for every proxy rule that reaches an application: report, review, then block.
4. Add bot and abuse rules, scoped to the traffic you mean.
5. Set security headers, and manage your Content Security Policy with ScriptAttest.
6. Protect editorial and preview hosts.
7. Keep tokens out of source control, and rotate them after any exposure.
8. Write and test a break-glass runbook before you need it.

Serve static first

A request that Quant answers from static content runs no application code, so an application vulnerability (for example a PHP or Node.js CVE) cannot be reached through it.

• Publish your site as static output. For Drupal or WordPress, push the rendered pages and files to a static project, and keep the CMS as an editorial system.
• Add a proxy rule only for a path that must run code, for example a form handler, search, an API or a login. Scope the rule’s URL to that path. Do not proxy * on a public static project.
• Review your proxy rules from time to time. A rule that was added as a temporary fix, for example “proxy on 404” for files the CMS did not publish yet, keeps a path open to the application. Fix the publish step, then disable or delete the rule.

Lock the origin to Quant

Restrict the origin so it accepts only requests through Quant, for example at its firewall or with a secret header that your origin checks. Then all traffic passes through your Quant project and its rules. Origin Protection for Quant Cloud containers is being verified; see the note on the Origin Protection page.

WAF: report, then block

The WAF inspects requests on proxy rules. Static content is not inspected, because no application handles it.

1. Turn on the WAF for each proxy rule that reaches an application. The WAF is enabled per organisation, so contact support if you do not see the setting.
2. Start in report mode. The WAF logs what it would block, and blocks nothing.
3. Leave it in report mode during normal traffic and normal editing. A few days is typical.
4. Read Security & WAF > WAF logs. Look for hits on requests your users or editors make on purpose.
5. Add the rule IDs of those false positives to Allow rule IDs. Use paranoia level 1 unless you have a reason to raise it.
6. Switch the rule to block mode, and watch the log for the first days.
7. Add rate limits for login, form and API paths, in report mode first.

When a security review asks whether you are behind a WAF, answer per proxy rule: which rules have the WAF on, and in which mode. Report mode does not block. Step-by-step detail: Configure the WAF.

Bot and abuse rules

• Scope a bot challenge rule to the traffic you mean, for example cloud, VPN, Tor exit and abuser networks, or countries outside your audience. An unscoped challenge also stops real visitors and search engines.
• Use page rules with country, IP or ASN conditions to block a source that you have seen in the WAF log.

Security headers and CSP

New projects start with Strict-Transport-Security, X-Content-Type-Options and Referrer-Policy. Review and add headers on Security & WAF > Headers. See Improve your security headers.

A Content Security Policy (CSP) tells the browser which scripts, styles and connections a page may use, so an injected script cannot run. A CSP is specific to each site and must change when your tags and vendors change. Use ScriptAttest to build the policy, test it in report-only mode, and keep it current. ScriptAttest links to your Quant project and writes the CSP header for you. See Content Security Policy with ScriptAttest.

Editorial and preview hosts

A CMS that publishes to a static site still runs code, so protect its host:

• Put a password rule or an auth function in front of the editorial domain, above the proxy rule. Exempt only the paths that must be public.
• Restrict the CMS origin so it accepts only requests through Quant.
• Turn on the WAF on the proxy rule to the CMS.
• Use two-factor authentication for CMS accounts. Keep the CMS and its base image up to date, and redeploy after a base image security release.
• Protect preview and staging domains the same way. They often run older code.

Tokens

• Do not commit quant.json or any token to source control. Use CI secrets and environment variables.
• Use dashboard API tokens scoped to the organisations they need.
• After any exposure, rotate the project token: select the project, Project > Integrations, then Rotate token next to Token. Choose when the old token stops working: after 24 hours, after 7 days, or now. A linked GitHub repository gets the new token automatically. Update every other copy (CMS module, other CI) yourself.

Break-glass runbook

When a critical vulnerability affects your CMS or application, a site with a static copy can keep serving its public pages while you fix the application. You disable the proxy rules, so the edge serves the static copy, and you enable them again when the fix is live. Write the runbook down and test it once before you need it.

The runbook also covers what to do around the switch: make a complete copy beforehand, close the other routes to the application, stop the application at its own address, stop content pushes and scheduled crawls, purge the cache after each switch, and test. See Break-glass: switch the site to its static copy.

Another CDN or WAF in front of Quant

We do not recommend putting another CDN or WAF in front of a Quant project. Quant then sees that provider’s addresses instead of your visitors’, so:

• WAF logs, access logs and rate limits show the provider’s IP addresses, not your visitors’;
• country, IP, ASN and traffic-source rules and the bot challenge act on the provider, not the visitor;
• content sits in two caches, and a Quant purge does not clear the other cache.

The Quant WAF in block mode, scoped bot rules, a locked origin and a static-first design cover the same need. If your organisation requires another provider, contact support before you change DNS.