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.

A better backup solution

When Fedora 13 hit the streets I was excited to see a new backup solution, Deja Dup, included in the distribution. For the past several months I've been using my own version of a backup solution, namely rsync rdiff-backup, which always felt a little cobbled together. But now I have …

Sparks's Journal

Other articles

A better backup solution