So far I’ve added the easy headers: Strict-Transport-Security, X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, and Referrer-Policy. The complicated one, at least for sites using WordPress, is the Content-Security-Policy. Unfortunately, the Content-Security-Policy is the best protection against XSS attacks. As I pointed out above, WordPress uses several inline scripts and CSS instructions. This means that I’d have to use “unsafe-inline” when describing what is allowed for scripts and styles. Unfortunately, adding that negates much of the protections offered by the policy.
There is a way around doing this while still allowing inline scripts: using a nonce. Of course this isn’t really possible with code that one doesn’t directly control, like the WordPress Core. I did, however, find a potential fix that may be forthcoming that I’ll be monitoring. This enhancement would allow for a plug-in to add a nonce to these scripts, thus allowing a Content-Security-Policy to be defined to allow those specific scripts. Until then, I’ll have to leave this site somewhat unprotected like many (most?) websites are today.