Server recipe
Security headers in TYPO3
TYPO3 can send every header itself, with one configuration array and no extension. What it cannot do is cover the files your web server delivers without ever asking TYPO3.
01 Where it goes
The frontend headers array, not a TypoScript afterthought
TYPO3 sends the headers listed in the FE headers configuration with every frontend response. Put the array in config/system/additional.php, which is read after the generated settings.php and, unlike settings.php, is not rewritten when someone saves in the install tool.
The limit is in the name: FE means frontend. Files under fileadmin and the compiled assets are delivered by Apache or nginx without TYPO3 running at all, so they receive none of these headers. If the web server is yours, set them there instead and leave this array out; if it is not, keep the array and know that your images and stylesheets go out bare.
02 The recipe
Paste this into config/system/additional.php
A safe starting point for a frontend that loads its own assets. X-Frame-Options is SAMEORIGIN rather than DENY on purpose: the backend previews pages in an iframe on the same origin, and DENY leaves your editors looking at an empty box.
<?php $GLOBALS['TYPO3_CONF_VARS']['FE']['headers'] = [ 'Strict-Transport-Security' => 'max-age=63072000; includeSubDomains',
'Content-Security-Policy' => "default-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'",
'X-Frame-Options' => 'SAMEORIGIN',
'X-Content-Type-Options' => 'nosniff',
'Referrer-Policy' => 'strict-origin-when-cross-origin',
'Permissions-Policy' => 'geolocation=(), camera=(), microphone=(), payment=(), usb=()', ];Two adjustments before this is yours. The Content-Security-Policy allows nothing from third parties and will block embedded maps, fonts, analytics and most extensions that load anything external, so start with Content-Security-Policy-Report-Only. And the backend is a separate question: TYPO3 12 and later carry their own backend policy, configured in Configuration/ContentSecurityPolicies.php, which this array does not touch.
03 Line by line
What each entry does
Every entry from the block above on its own, so you can leave out what does not fit your site rather than pasting something you cannot explain.
Strict-Transport-Security
What it does. Commits browsers to reaching your site over HTTPS only, for two years. Set it at the web server if you can, so it also covers requests that never reach TYPO3, and do not add it until HTTPS works on every subdomain.
'Strict-Transport-Security' => 'max-age=63072000; includeSubDomains', Content-Security-Policy
What it does. Start here rather than with the enforcing header. Report-only changes nothing for visitors but tells you what a strict policy would have blocked, which on a TYPO3 site with a handful of extensions is usually more than expected.
'Content-Security-Policy' => "default-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'",
'Content-Security-Policy-Report-Only' => "default-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'; report-uri /csp-report", X-Frame-Options
What it does. SAMEORIGIN rather than DENY, because the backend page preview loads the frontend in an iframe. DENY breaks it, and your editors will report it as the website being down.
'X-Frame-Options' => 'SAMEORIGIN', X-Content-Type-Options
What it does. Tells the browser to trust your declared content types rather than guessing. Safe on any site, and on one where editors upload files it removes a whole class of upload-based attack.
'X-Content-Type-Options' => 'nosniff', Referrer-Policy
What it does. Sends the full URL within your own site and only the bare domain to anyone else. The right value for almost every public TYPO3 site.
'Referrer-Policy' => 'strict-origin-when-cross-origin', Permissions-Policy
What it does. Switches off camera, microphone, geolocation, payment and USB access for your pages and anything they embed. Extend the list rather than shortening it: a feature you do not name stays available, including to whatever an extension embeds.
'Permissions-Policy' => 'geolocation=(), camera=(), microphone=(), payment=(), usb=()',04 Verifying it
Flush the cache, then read the response
The headers are added per response rather than stored with the cached page, so a TYPO3 cache flush is not strictly required. A reverse proxy in front of TYPO3 is a different matter: it stores headers along with the body, and it will keep serving the response it captured before your array existed.
vendor/bin/typo3 cache:flush curl -sI https://example.com | grep -i "^strict-transport\|^content-security\|^x-frame" curl -sI https://example.com/fileadmin/logo.png | grep -i "^x-content-type"Check a file under fileadmin as well as a page. If the header is on the page and missing on the file, that is the frontend-only limit described above and not a mistake in your configuration.
05 Questions
What people ask about TYPO3 headers
Should I use the TypoScript additionalHeaders setting instead?
It works, and on an older installation it may be what you already have. The FE headers array applies to every frontend response including error pages, lives in one file rather than in each TypoScript template, and does not depend on a template being loaded at all. If both are set you can end up with the header twice.
My backend broke after adding the Content-Security-Policy. Why?
It should not have, because this array is frontend-only. If the backend really is affected, the header is coming from your web server rather than from TYPO3, and the fix belongs there: exclude the backend path or give it a policy of its own.
Does this work in TYPO3 11?
Yes, the frontend headers configuration has been there since version 10. What changed later is the backend side: the dedicated Content Security Policy for the backend arrived with version 12, and before that a strict backend policy had to come from the web server.
What about extensions that send their own headers?
They can, usually through a PSR-15 middleware, and then two values for the same header go out. Search your extensions for header and withHeader calls before assuming this array is the only source, and pick one owner per header.
06 In depth
The headers in detail
This page is the configuration. These guides are what each header actually does and how to choose its value.
HTTP security headers
What each response header does, which ones your site should send and how to configure them correctly.
Content Security Policy
The strongest defence against cross-site scripting: which directives to set, how to roll a policy out in report-only mode and how to reach an enforcing policy without breaking your site.
HSTS
Strict-Transport-Security explained: what max-age, includeSubDomains and preload actually do, and why the preload list is a decision you cannot quickly undo.
Cookie security
Secure, HttpOnly and SameSite: the cookie attributes that keep a session out of reach of scripts and cross-site requests, with the settings for a typical stack.
Clickjacking and X-Frame-Options
How an invisible overlay turns a visitor click into an action on your site, and the two headers that stop it: X-Frame-Options for older clients, frame-ancestors for everything else.
Referrer-Policy
Which part of your URLs travels to other sites when a visitor clicks away: the five policy values that matter, what each one gives up and the one to set by default.
Permissions-Policy
Switch off camera, microphone, geolocation and payment for your site and everything it embeds: the allow-list syntax, and why a feature you did not name is not a feature you turned off.
SPF, DMARC and DNSSEC
The records that stop someone sending mail in your name, and the one that keeps your DNS answers honest: what each does and the order to introduce them in.
security.txt
The file that tells a researcher where to report a vulnerability. Two mandatory fields, ten minutes of work, and the difference between a private report and a public one.
Monitoring security headers
A header that is right today can be gone after the next deploy. Three ways to notice: a cron job with curl, a check in your CI pipeline and a scheduled scan, with what each of them catches and misses.
Detecting CSP changes
How a policy changes quietly through deploys, plugins and CDN rules, and how to catch it: a header diff, violation reports through report-to, and what a scan comparison can and cannot show.
Keep reading
More guides
Every guide stands on its own, and together they cover what our scanner looks at. Pick the one closest to your next question.
See which headers TYPO3 is really sending
Our free Quickscan reads the headers from your live response rather than from your configuration file, and explains every finding in plain language.