Add security HTTP headers to nginx config

Following the cybersecurity training.

You should also consider adding an immutable 1-year cache to CSS and JS assets for performance reasons (as long as they have hashes in their filenames for cache busting, which they should already; so just need to check if there are any JS/CSS file without hashes in their file names).

Adding the CSP header is a lot more complicated, so I didn't do it. You could try adding one in report mode to see.

changed the description

added 1 commit

• 69d187fb - Edit nginx.conf

Compare with previous version

Hi Axel,

A couple of question: Is there nothing in REACT that manages the CSP headers for us? Do we want to deny the use of iframes?

 add_header X-Frame-Options "DENY";

Up to you. Just to clarify, this header forbids data.esrf.fr from being itself embedded in an iframe. I could be mistaken, but I don't think the portal is meant to be embedded, so I'd argue that yes, this header is good to have.

---

CSP can be defined on the server via an HTTP header, or in the front-end via a meta tag in the head of the page. In React 19, it's possible to render meta tags like any other elements; in React 18 and below, one needs to use a library like React Helmet (which you probably already have installed).

To start with, the simplest is to add an HTTP header in my opinion. No hash, no nonce, just simple directives. As the trainer explained, a first step would be to come up with an initial CSP declaration that is pretty strict but set to report-only, with an endpoint to collect the reporting data:

Content-Security-Policy-Report-Only: default-src 'self'; img-src 'self'; ...; report-to csp-endpoint
Reporting-Endpoints: csp-endpoint="https://example.com/csp-reports"

Thanks for the clarification!

I do not see any use case for the data portal to be embedded, but I do not know what others partners want to do with it. At some point, there was some discussion about including it as an iframe in MXCuBE so people could see the results within the data acquisition.

Is it a risk that people can use it embedded?

No worries, it's to prevent clickjacking attacks. Not hugely critical, but . For other partners, I assume they would have control over the configuration of the static web server? For MXCuBE, I'd suggest opening a new tab.

I presume we can be conservative on this and remove in case we need to embed this somewhere...

approved this merge request

added 1 commit

• beded1af - Remove `X-Frame-Options` header

Compare with previous version

added 19 commits

• beded1af...e5d5b566 - 18 commits from branch main
• 78c1fef2 - Add security headers to nginx config

Compare with previous version

added 3 commits

• 78c1fef2...09449be7 - 2 commits from branch main
• d1e82497 - Add security headers to nginx config

Compare with previous version

enabled an automatic merge when all merge checks for d1e82497 pass

merged

mentioned in commit 59c702fe