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.