Not by default. Preview deployments often show unreleased pages, draft copy and staging settings, so restrict access to people who need it, keep test data in them, and delete them when the pull request closes. Make a preview public when everything in it is already meant to be public.
What a preview can expose
A preview is a full build of a branch at its own address. Depending on how you set it up, it may include:
- Content that is not yet announced, such as a launch page or pricing change.
- Draft entries pulled from a headless CMS using a preview token.
- Feature flags and test endpoints that production does not have.
- Environment values for staging services.
- Source maps and debug output that production strips.
Search engines and link unfurlers can find preview URLs if they are linked anywhere, including in a public pull request comment.
A decision guide
| Preview content | Recommended access |
|---|---|
| Public marketing page, all content already live | Public is acceptable |
| Unreleased copy or design | Authenticated, team members |
| Draft CMS content | Authenticated, and a server-side check, not a client flag |
| Anything using staging credentials | Authenticated, with narrow credentials |
| Pull requests from forks | Do not build with secrets at all |
Controls to set
- Authentication in front of previews. Use the hosting platform's access control feature if it has one, or a single sign-on layer at the edge. A shared password is better than nothing, but it is hard to revoke.
- Noindex. Send a robots directive on preview hosts. This is a courtesy to crawlers, not a security control, so do not rely on it for secrets.
- Short lifetime. Delete previews when the branch merges or closes. Stale previews are the ones nobody remembers to protect.
- Separate credentials. Previews should use test keys with the least access that works. Never give a preview the production write token.
- No secrets for untrusted code. If your CI builds previews for pull requests from forks, do not expose deployment or API secrets to those builds. Untrusted code in a pull request can print any variable it can read.
- Hostname hygiene. Use a predictable preview domain separate from your production domain, so cookies set on production are not shared. If preview shares a parent domain with production, cookie scope becomes a question to review.
Check what you already have
- List active preview URLs from the hosting dashboard or API.
- Open each in a private window. If it loads, ask whether you would be comfortable seeing that page in a search result.
- Check your public pull requests for pasted preview links.
- Look for old previews tied to branches that no longer exist.
Related habits
Pair this with dependency hygiene. A preview build installs packages just like production, so a malicious package would run there too. Scan the lockfile before the build, not after.
Where Safeguard fits
Safeguard can gate pull requests on dependency findings before a preview is built, and scan the repository continuously. Free scan: gold.safeguard.sh/scan.
Quick check
Is an unguessable preview URL enough protection?
No. A random URL leaks through logs, screenshots, referrer headers and pasted links. Use real access control.
Do previews need the same security headers as production?
Yes, so you catch header problems before release. See HTTP security headers explained.
Last reviewed: 19 October 2026.
