[Evergreen-dev] Towards better security headers by default

[Dan Scott]

I was recently tasked by our IT team to start enhancing the security
headers of our library web sites. I noticed that Ex Libris Alma, to which
we are (sadly) migrating and which is a hosted solution out of our control,
receives an F on the Mozilla Observatory scan (
https://observatory.mozilla.org/)

I checked our Evergreen instance, and it received a D+ due to the use of
our HSTS header. Better, but we should probably provide good defaults out
of the box.

Adding the following headers via our nginx proxy brought the score up to a
B+:

# HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
add_header Strict-Transport-Security max-age=15768000;

# security headers
add_header Content-Security-Policy "default-src https: wss: 'unsafe-inline'
'unsafe-eval' ; frame-ancestors 'self'";
add_header X-XSS-Protection "1; mode=block";
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;

We could create a stricter CSP for the catalogue under /eg/opac/ by adding
hashes or nonces to the few inline scripts and styles that show up there
(although I'm admittedly unfamiliar with the Bootstrap catalogue), but the
staff client is pretty much a lost cause--Dojo requires 'unsafe-inline'
'unsafe-eval' which renders the CSP pretty much moot. Any catalogue
functionality that still requires Dojo will suffer similarly.

Perhaps this is something that could be added to the standard
out-of-the-box experience? Or at least documented?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-dev/attachments/20201119/e8a56779/attachment.html>