Content Security Policy HTTP headers and Omeka S

Omeka S Accessibility
1

[Not sure if this is the correct forum for this, but Accessibility seems close enough… If it isn’t right, let me know…]

Our Omeka S instance has been flagged by central IT using Security Score Card. The sin?

“Subresource Integrity”

Description
Subresource Integrity (SRI) is a security feature in web development designed to ensure the integrity of externally loaded resources on a webpage. These include scripts, stylesheets, and fonts. With SRI, developers include a cryptographic hash of the expected resource content in the HTML. When a user visits the webpage, the browser checks this hash against the actual content fetched from the external source. If the hashes match, that means the resource hasn’t been tampered with or compromised.

Risk
Without SRI, externally loaded resources, like scripts and stylesheets, lack integrity verification. This makes them susceptible to tampering. This creates a potential avenue for attackers to inject malicious scripts, which leads to Cross-Site Scripting (XSS) vulnerabilities, unauthorized data access, and other security threats.

Recommendations

  • Ensure accurate cryptographic hashes are specified for all externally loaded resources using SRI attributes in the HTML.
  • Routinely review and update cryptographic hashes to align with changes in resource content.
  • Implement robust input validation and sanitization practices to prevent injection attacks.
  • Use CSP to restrict resource sources. This adds an extra layer of control over content execution.
    –
    Is there anything in Omeka S, or any available modules that would allow us to alter the Content Security Policy (CSP) in Omeka’s http headers.

This is way outside of my comfort zone, of course.

2

We don’t ship with a Content-Security-Policy header.

It’s possible to set it yourself, though. Probably the easiest way is through the .htaccess file, where you could add a line like:

Header always set Content-Security-Policy "your policy here"

Of course, you’d need to know what policy you’d want to set. Maybe you could get guidance on that from your IT. Something like the following should work fine for a vanilla Omeka S installation, but won’t be particularly restrictive:

Header always set Content-Security-Policy "script-src-elem 'self' 'unsafe-inline' code.jquery.com; style-src 'self' 'unsafe-inline' fonts.googleapis.com; font-src 'self' fonts.gstatic.com"

On subresource integrity, we’re not currently setting that either on the external resources we load. Omeka S doesn’t require a whole lot of external assets, and there’s a setting that disables external loading that you can add to your config/local.config.php, before the final ]; line:

    'assets' => [
        'use_externals' => false,
    ],

This will take the external load we do for jQuery and use a local copy instead. In a vanilla install I think the only other thing you’d have to worry about as an external asset would be the Google font(s).