Security Headers for a web API

Question

I just got a setup, a golang web api behind a caddy server that has HTTPS by default via Let's Encrypt, the server proxies all requests to the web api. So I went around to test my webserver "security" on sites such as securityheaders.io. They gave me an F, so I added the headers they demanded and I got an A

Access-Control-Allow-Methods "GET, POST, OPTIONS"
Strict-Transport-Security "max-age=31536000;"
Content-Security-Policy "script-src 'self'"
X-XSS-Protection "1; mode=block"
X-Content-Type-Options "nosniff"
X-Frame-Options "DENY"
-Server

These are the headers I currently have, but I'd like to know if they are necessary for security when what I'm making is not a website but rather a API webserver, something like

Access-Control-Allow-Methods "GET, POST, OPTIONS"
-Server

So basically, all those security headers necessary if you want to just request your API?

Answer 1

Checking headers off a list is not the best technique to assert a site's security. Services like securityheaders.io can point you in the right direction but all they do is compare against a list of proposed settings without any context about your application. Consequently, some of the proposals wont't have any impact on the security of an API endpoint that serves nothing but JSON responses.

• Strict-Transport-Security makes sense because it guarantees that users will directly connect to your site via HTTPS after their first visit and until the max-age timeout is reached - thereby preventing downgrade attacks. Even an API endpoint should be secured with SSL, so keep that header.

• Access-Control-Allow-Methods: GET, POST, OPTIONS is not a security option per se. If your API works via CORS preflight requests you need to decide which methods you allow for cross-origin sites to use. Disabling CORS could make your API unavailable. If that particular setting is sensible depends on your implementation.

• X-XSS-Protection: 1; mode=block can be good adivice for regular sites because it instructs the XSS Auditor (which is implemented in WebKit browsers but not Firefox) to not render the site when it detects a reflected XSS attempt. But for an API that just provides JSON responses and doesn't serve active content, this header doesn't bring any benefit.

• X-Content-Type-Options: nosniff prevents browsers from making assumptions about the content type if the site didn't declare the type correctly. If you're running a JSON API you should serve the responses with Content-Type: application/json. If you do that correctly there will be no need to add the nosniff directive.

• X-Frame-Options: Deny prevents any website from embedding your site in an HTML frame. That option stops clickjacking attacks where an attacker tricks users into interacting with your website through a disguised frame. But without interactive elements there is limited risk through cross-origin framing. Yet, as there are advanced attacks involving dragging content out of the frame which could disclose JSON responses, you might still want to leave that header there.

• Content-Security-Policy headers control what kind of content from what origin your site is allowed to interact with (scripts, stylesheets, images, etc.). Your setting "script-src 'self' means that only scripts from the same origin may be loaded. A CSP is useful for regular sites but doesn't make sense for your API endpoint because you don't serve any active content that could be controlled by the CSP.

• The Server header specifies information about the server and the software running on it. It's often advised to not send that header at all to not disclose anything about backend software and versions.