Apache Hardening

There are various ways that Apache configuration can be hardened to make it more secure. The suggested configuration changes below are informed by https://securityheaders.com/ Much of this is quite generic and could be applied to an web host not just an EPrints repository but some needs be be specifically configured for an EPrints repository.

HTTP Strict Transport Security (HSTS)

HSTS ensures that a visitor's (to your EPrints repository) web browser only uses HTTPS, once they are aware HTTPS is available. It is now quite common to setup an Eprinst repository to be only HTTPS with HTTP redirects. If this is the case only your visitor's first request will be HTTP and then their web browser will know to use HTTPS from there on.

The following line should be added to near the top of the HTTPS virtualhost, (i.e. in the archive's ssl/securevhost.conf):

Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

The max-age=31536000 is the recommended length in seconds (365 days, i.e. approx. 1 year). includeSubDomains is not absolutely necessary unless the repository has alternative hostnames that are under the primary hostname (e.g. www.example.eprints.org is a secondary hostname for example.eprints.org). preload is only really useful if your repository is the root of a domain (e.g. eprints.org) is on browsers preload lists (e.g. [1]). This will make sure that even the first request for your repository is rewritten to HTTPS before being submitted by your visitor's web browser.

X-Frame-Options (Clickjacking)

Clickjacking is where someone embed your website (e.g. EPrints repository) within their website to trick you into clicking on something you would not normally click. Generally there is no good reaso to allow your repository to be embedded on another website, so the following line should be used.

Header always append X-Frame-Options SAMEORIGIN

This can be put in its own file under Apache's configuration directories, as it is best to make sure it is applied to all virtualhosts.

Permissions Policy

Permissions Policy (formerly known as Features Policy but using different syntax), is intended to set out what access your EPrints repository might need to certain peripherals / sensors / features your visitor's web browser might have access (e.g. webcam, microphone and geolocation). EPrints repositories do not generally need access to any of these but if your repository was compromised (e.g. someone uploaded some JavaScript that would be executed if a user requested a certain page), it is sensible to explicitly specify access is not required, so these peripherals/data could not be misused.

The following line states that your EPrints repository does not need access to a visitor's computer's camera, geolocation or microphone.

Header always set Permissions-Policy "camera=(), geolocation=(self 'HOST_URL'), microphone=()"

Make sure you update the HOST_URL with the primary hostname URL of your repository (e.g. https://example.eprints.org/). Like for Clickjacking protection line, this is best added to its own file under Apache's configuration directories, so it applies to all virtualhosts. New peripherals, sensors and features continue to be added to the Permissions Policy. The line above is only intended to cover the most significant. You can build your own permissions policy at https://www.permissionspolicy.com/ and update the above line as appropriate.

Referrer Policy

Referers is an important part of how the Web works but it also means private information can be leaked between one website and another, often in a way where it could be intercepted. Referer Policy can ensure the private part of this information (i.e. specificially what you were accessing on the referring website ) is not sent to the referred website. Also the information that is being sent can only be sent if this would be over HTTPS, so it cannot be intercepted. Therefore, the following Referer Policy line is recommended:

Header set Referrer-Policy "strict-origin-when-cross-origin"

Like for Clickjacking protection and Permissions Policy lines, this is best added to its own file under Apache's configuration directories, so it applies to all virtualhosts. strict-origin-when-cross-origin will only send referer information to the website click on if the link is HTTPS. If the website is not the same website (i.e. the origin), then it will only send the hostname of the refering website not the full URL, which could contain private information.

Content Security Policy

Content Security Policies are one of the more complex aspects to configure in Apache. There purpose is to cover from where aspects of the page (e.g. JavaScript, CSS, images, fonts, etc.) can be provided. Also, it covers how they can be provided, mainly in the case of JavaScript whether they can be inline or evaluated scripts. EPrints repository software currently uses some inline scripts, so the benefits of the Content Security Policy are limited due to this. However, EPrints repository software development is working towards eliminating use of inline JavaScript, so that a more secure Content Security Policy can be used. At present the following policy is recommended. It should work for vanilla EPrints repositories that only use common Bazaar plugins (e.g. IRStats2, etc.):

Header set Content-Security-Policy "default-src 'none'; script-src 'self' 'unsafe-inline' www.google.com www.gstatic.com; connect-src 'self'; img-src 'self'; style-src 'self' 'unsafe-inline' www.gstatic.com; base-uri 'self'; form-action 'self'; font-src 'self'

Like other Apache hardening configuration, this is best added to a file under Apache configuration directory so it is applied to all virtualhosts. However, if you are running other websites that do no have inline JavaScript, it may be better to add this line inside the HTTP and HTTPS virtualhosts for the EPrints repository in their archive's cfg/apachevhost.conf and ssl/securevhost.conf configurations.

The policy above currently only includes 'unsafe-inline' needed for inline JavaScript. It has been reported that sometimes EPrints repositories will use evaluated JavaScript, so it may be necessary to add 'unsafe-eval' to the script-src section.

It is to be expected that many bespoke modifications or addition of Bazaar plugins will lead to you needing to update your Content Security Policy. In particular if your rebranding your repository, as this will commonly use CSS, JavaScript, images and fonts from remote hosts.