Server recipe
Plesk generates your web server configuration, and it regenerates it whenever anything about the domain changes. There is exactly one place where your directives survive that, and it is not the file you found first.
01 Where it goes
Plesk writes the nginx configuration for each domain into its own vhost directory and rewrites that file from its database whenever the domain, its hosting settings or its certificate change. Edits there are not merged, they are lost, and usually weeks later when nobody connects the two events.
The supported place is Apache and nginx Settings for the domain, in the field for additional nginx directives. Plesk stores the text and includes it into the server block it generates, as vhost_nginx.conf. On the command line the same file sits in the conf directory of the domain and takes effect after a reconfigure. Either way you are editing an include that Plesk knows about rather than output that it owns.
02 The recipe
A safe starting point for a site served by Plesk with nginx in front. The directives go in without a surrounding server block: Plesk places them inside the one it generates for the domain.
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
add_header Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'" always;
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), camera=(), microphone=(), payment=(), usb=()" always; Two adjustments before this is yours. The Content-Security-Policy allows nothing from third parties, so embedded maps, fonts or analytics will be blocked and it should go out in report-only mode first. And if the domain runs Apache behind nginx with proxy mode on, check whether your application or a .htaccess is sending the same headers, because then both go out.
03 Line by line
Every directive 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. Plesk can also switch HSTS on per domain in its SSL/TLS settings, and if you use that, leave this line out rather than setting the header twice.
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always; 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, and on a panel-managed server you rarely know everything the site loads.
add_header Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'" always;
add_header Content-Security-Policy-Report-Only "default-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'; report-uri /csp-report" always; X-Frame-Options What it does. Stops your pages being embedded in a frame anywhere. Use SAMEORIGIN if part of your own site frames another part.
add_header X-Frame-Options "DENY" always; X-Content-Type-Options What it does. Tells the browser to trust your declared content types rather than guessing at them. There is no site where this value is wrong.
add_header X-Content-Type-Options "nosniff" always; 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 website.
add_header Referrer-Policy "strict-origin-when-cross-origin" always; 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.
add_header Permissions-Policy "geolocation=(), camera=(), microphone=(), payment=(), usb=()" always; 04 Verifying it
Saving in the panel applies the change for you. Editing the file over SSH does not: Plesk has to rebuild the server block before nginx sees your include, and until it does, the file sits there looking correct and doing nothing.
plesk sbin httpdmng --reconfigure-domain example.com curl -sI https://example.com | grep -i "^strict-transport\|^content-security\|^x-frame" curl -sI https://example.com/logo.png | grep -i "^x-content-type" Check an image or a stylesheet as well as a page. With smart static file processing switched on, nginx serves those from a location of its own, and the nginx inheritance rule applies here too: a location that defines its own add_header discards every inherited one.
05 Questions
Because Plesk regenerates that file from its database whenever anything about the domain changes, including a certificate renewal you never touched. Put the directives in the additional nginx directives field, or in vhost_nginx.conf, both of which Plesk includes rather than owns.
Only if nginx is not in front, which on a default Plesk installation it is. With proxy mode on, nginx hands the request to Apache and both layers can add headers, so you end up with duplicates. Pick the outermost layer, which is nginx, and leave the Apache field alone.
No, the field is per domain and has to be repeated for each one. On a server with many domains a service plan or a server-wide nginx configuration file is less to maintain, but verify after the next Plesk upgrade that it is still being included.
Plesk runs a real nginx configuration test before saving, so the error is genuine rather than a panel quirk. The usual causes are a stray server block around the directives, an unescaped semicolon inside a header value, or a directive that is not allowed at that level.
06 In depth
This page is the configuration. These guides are what each header actually does and how to choose its value.
What each response header does, which ones your site should send and how to configure them correctly.
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.
Strict-Transport-Security explained: what max-age, includeSubDomains and preload actually do, and why the preload list is a decision you cannot quickly undo.
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.
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.
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.
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.
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.
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.
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.
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
Every guide stands on its own, and together they cover what our scanner looks at. Pick the one closest to your next question.
Our free Quickscan reads the headers from your live response rather than from your panel, and explains every finding in plain language.