For your protection, I've been working on securing this
website
with all the proper security HTTP
headers.
Of course, by running WordPress as the
backend, I'm making it easy to manage all the data but making it
difficult to manage all the pieces and parts of the system's backend.
The largest problem I've found are the many inline javascript and inline
CSS scripts that are in WordPress Core.
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.