Review redirect and header rule files the way you review code: read each rule for what it matches, what it sends visitors to, and what it leaves unprotected. Watch for wildcard matches that create open redirects, rules that shadow each other, and headers that apply to some paths but not others.
Static hosts usually let you describe redirects, rewrites and response headers in a plain config file kept in the repository. That file runs on every request at the edge, so a small mistake affects the whole site.
What to look for
Open redirects. A rule that forwards to a destination taken from the request, such as a query parameter, lets an attacker craft a link on your domain that lands a victim on a hostile page. Redirect targets should be fixed paths or a short allow list you control.
Greedy wildcards. A pattern like a path prefix with a catch-all can capture more than you meant. Test it with paths you did not intend to match, including encoded characters and trailing slashes.
Rule order. Many platforms apply the first matching rule. A broad rule placed early can make a later, stricter one unreachable. Read the platform's documentation on precedence for your host.
Header coverage. Security headers set for the site root may not apply to every path, especially if rules match specific extensions. Check a sample of paths: a page, a script file, an image and an error page.
Cache interaction. Headers on cached responses stay until the cache is purged. After a header fix, confirm the new value is served, and purge if it is not. See purge the CDN cache after a security fix.
A review checklist
- Does any rule build its destination from user input?
- Does every redirect go to HTTPS?
- Is the preferred host enforced, so alternate hostnames do not serve a second copy of the site?
- Do security headers appear on HTML responses, and are they set consistently? The headers that matter most for most sites are listed in HTTP security headers explained.
- Is the referrer policy deliberate? MDN notes that modern browsers default to strict-origin-when-cross-origin when no policy is set, but being explicit documents your intent.
- Are old redirects still needed, and do any point at domains you no longer control?
- Does the config file have a code owner, so changes need review?
Test with curl
You can check live behaviour without a browser.
curl -sI https://example.com/old-path
curl -sI https://example.com/ | grep -i -E "strict-transport|content-security|x-content-type|referrer"
Look at the status code and Location header on the first, and the presence of headers on the second. Repeat for several paths. Save the commands so the same check runs after every change.
Make changes reviewable
Put the config file under code owners, run the curl checks in CI against a preview, and keep a short comment above each rule explaining why it exists. A rule nobody can explain is a rule nobody will dare remove.
Where Safeguard fits
Rule files are configuration, and dependency scanning will not read them. Safeguard helps around them with policy gates on pull requests and continuous scanning of the packages in the same repository. Free scan: gold.safeguard.sh/scan.
Quick check
Is a redirect to another path on my own site ever risky?
Rarely, but check that it cannot be chained into a destination taken from user input.
Who should own the rules file?
A named code owner, so every change gets a second pair of eyes.
Sources
- MDN, Referrer-Policy header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy
Last reviewed: 19 October 2026.
