ref: 94680b3c3689fb0e610c23bbac5defd4191da5f0 bibliogram-docs/docs/HTTP headers.md -rw-r--r-- 3.9 KiB
94680b3cCadence Ember Update instances list 7 months ago

#HTTP headers

Bibliogram sets some HTTP headers for security reasons. Most of these are so that in the very unlikely event of an attacker interfering with a page, the attacker will have very limited access.


  • default-src 'self'; frame-ancestors 'none'; block-all-mixed-content

This disallows the page from accessing resources hosted on other domains, as well as inline scripts and styles. This can severly limit an attacker's ability to interfere with the site, because even if they get the ability to insert any content into a page, any inserted scripts will not execute.

This also disallows other sites from embedding Bibliogram in a frame. Frames can lead to an attack called "clickjacking", where the user is convinced to click on a button, but that button does nothing and is positioned over a functional button from the target site inside a frame.

Enigma Software discusses clickjacking attacks on Facebook.

Learn more: Watch on CloudTube / YouTube / Invidious


  • nosniff

Some poorly coded websites may not serve resources with the correct Content-Type header. In this case, the browser would normally try to guess the type of the resource depending on its content. Since Bibliogram's resources are all served with the correct Content-Type, setting this header asks the browser not to guess. This can prevent, for example, malicious scripts being detected and applied as stylesheets.

Learn how content type works, and how it can be abused: Watch on CloudTube / YouTube / Invidious.


  • strict-origin

The Referer header (yes, spelt like that) is sent to the target page whenever you click a link. It contains the URL of the page you were just on. Lots of people like to use this for tracking. The strict-origin setting for Referrer-Policy means that outgoing Referer headers will only have the origin (e.g. https://example.org) rather than the full URL (e.g. https://example.org/an/interesting/page). There is also a policy to not send a Referer at all, but having the origin is useful for form validation, to make sure that people submitting a form to Bibliogram are actually on Bibliogram.


  • accelerometer 'none'; ambient-light-sensor 'none'; battery 'none'; camera 'none'; display-capture 'none'; document-domain 'none'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; payment 'none'; publickey-credentials-get 'none'; sync-xhr 'none'; usb 'none'; xr-spatial-tracking 'none'

This disallows the page from using specific web platform features, such as asking for access to the camera, microphone, or location. Bibliogram doesn't need these features, so it sets this header to prevent potentially malicious scripts from using them.


There is one more header that is present on bibliogram.art, but which is not added to other instances by default, called Strict-Transport-Security, usually abbreviated "HSTS", which stands for "HTTP Strict Transport Security". If an HTTPS website has this header present and you visit it once, your browser will remember that it is HTTPS and will refuse to connect to it over insecure HTTP in the future. By design, this is very difficult to undo once it is applied, so Bibliogram does not add this header by default.

If you serve a Bibliogram instance on the public web, please read the following, then consider whether using HSTS is right for you.

Documentation of HSTS on MDN.

Read about HSTS preloading.