How to Prepare for Your First Penetration Test
A practical checklist for your first penetration test: how to set scope, prepare accounts and environments, pick contacts and keep communication clear.
Free tool
Security Headers Builder
Pick your options and copy ready-made security headers for your server or platform. Start strict, then add only the sources your site actually needs.
Runs entirely in your browser. Nothing you enter is sent to us.
Output for
How to use the result
Rolling out your headers safely
- Start in report-only mode for the Content-Security-Policy. Browse your whole site and check the browser console for anything that would be blocked.
- Add only the sources you need. Every extra domain is one more place an attacker could load script from.
- Switch to enforcing once the reports are clean, then re-check after each release that adds a third-party service.
- Be careful with HSTS options. includeSubDomains and preload are hard to undo. Only enable them once every subdomain serves HTTPS.
Headers are one layer of defence. They make some attacks harder but won't fix flaws in your application's logic or access control.
Background
What each header does
- Content-Security-Policy: lists where the browser may load scripts, styles, images and other resources from, which limits the damage of cross-site scripting. Its
frame-ancestorsdirective controls which sites may embed your pages. - Strict-Transport-Security (HSTS): tells browsers to use only HTTPS for your domain, so connections can't be downgraded to plain HTTP.
- X-Content-Type-Options:
nosniffstops browsers guessing a file's type, so an uploaded file can't be run as script. - X-Frame-Options: an older way to block framing, kept for older browsers alongside
frame-ancestors. - Referrer-Policy: controls how much of a page's URL is shared with other sites when people follow links.
- Permissions-Policy: turns off browser features you don't use, such as the camera, microphone or location.
- Cross-Origin-Opener-Policy: separates your page from windows opened by other sites.
Where to set them
Set headers in one place that every response passes through: your web server, load balancer, CDN or hosting platform. Headers set only in application code tend to miss error pages, static files and redirects.
How to check them
After deploying, open your browser's developer tools, reload the page and look at the response headers on the Network tab. Check a normal page, an error page and a static file such as an image, since each can be served differently.
FAQ
Security Headers Builder questions
Will a strict Content-Security-Policy break my site?
It can, which is why the builder offers report-only mode. In report-only mode the browser logs what it would block without blocking it, so you can fix the gaps before enforcing the policy.
Do I still need X-Frame-Options if I set frame-ancestors?
Modern browsers follow frame-ancestors and ignore X-Frame-Options when both are present. Keeping both protects older browsers, as long as the two agree.
Should I add my domain to the HSTS preload list?
Only when every subdomain, now and in future, will serve HTTPS. Preloading is built into browsers and is slow to undo, so a forgotten HTTP-only subdomain would become unreachable.
Do security headers replace a penetration test?
No. Headers reduce the impact of some attacks in the browser. They don't fix broken access control, injection or business logic flaws, which need testing to find.
Related
Web Application Penetration Testing
Manual testing of your web app's authentication, access control and business logic, the places scanners can't reach.