Treat a build hook URL as a credential. Keep it out of public code and chat, give each caller its own hook, rotate hooks on a schedule and after any exposure, and watch the deploy log for builds you did not expect. Anyone who holds the URL can start a build.
Static sites rebuild when content changes. A headless CMS, a spreadsheet script or a scheduled job calls a URL, and the hosting platform runs the build and publishes the result. The convenience is real. So is the risk.
What an exposed hook can do
A leaked hook rarely lets an attacker change your code. It does let them trigger builds repeatedly, which can burn build minutes, delay a real release, or publish whatever the build pulls from external sources at that moment. If your build fetches content from an API, an attacker who can alter that content and trigger a build gets it published.
Checklist
- One hook per caller. If the CMS and a cron job share a hook, you cannot tell which one was abused or revoke one without breaking the other.
- Store hooks as secrets. Put them in the secret settings of the calling system, not in a repository, a wiki or a ticket.
- Limit what the build does. A hook-triggered build should build the branch you intend. Check that the hook is pinned to a production branch and cannot be pointed at an arbitrary one.
- Check the caller. If the platform supports signed requests or IP restrictions, use them. If not, keep the hook secret and lean on monitoring.
- Rotate. Create a new hook, update the caller, then delete the old one. Do this on a regular rhythm and whenever someone with access leaves.
- Rate limit upstream. If you accept a webhook from a CMS and forward it to the build hook, add your own rate limiting so repeated calls do not create queues of builds.
- Log and alert. Review the deploy list for builds with no matching content change. An unexplained build is a signal.
- Verify the incoming side too. If your own function receives webhooks and then triggers a build, verify the sender's signature before acting. See five ways webhook receivers go wrong.
Where the content comes from matters
| Build input | Question to ask |
|---|---|
| Content API at build time | Who can edit that content, and is it reviewed before the hook fires? |
| Git repository | Is the branch protected? |
| Third-party feed | What does the page do if the feed is empty or hostile? |
| Environment variables | Are they scoped to production builds? |
A rebuild is as trustworthy as what it fetches. Sanitize content that comes from outside before it enters a page, and prefer a review step for anything that becomes public text or markup.
Rollback plan
Know how to redeploy the last good build quickly. Hosting platforms generally keep previous deploys, which makes recovery a matter of promoting an earlier one. Practise this once, so the first time is not during an incident.
Try it yourself
The continuous monitoring demo shows scheduled rescans catching changes after deploy. Compare it to your own setup and ask what would alert you to an unexpected rebuild.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard scans the dependencies each build installs and enforces policies on pull requests, so rebuilds do not quietly pull in a newly flagged package. Free scan: gold.safeguard.sh/scan.
Quick check
Is a build hook the same as a deploy key?
No. A deploy key lets a system read or write a repository. A build hook starts a build. Both need secrecy, but their blast radius differs.
How often should I rotate a hook?
Pick a regular schedule your team will keep, and rotate immediately after any exposure or staff change.
Last reviewed: 19 October 2026.
