API Security: Secure Headers | Primathon

Introduction

From banks, retail and transportation to IoT, autonomous vehicles and smart cities, APIs are a critical part of modern mobile, SaaS and web applications.

As a result APIs tend to reveal private and sensitive data which attracts many attackers.
Although API Security is very important, Every data is not the same and thus requires safety measures tailored to it

Headers

Whenever a browser requests a page from a web server, the server responds with the content along with HTTP response headers. Some of these headers contain content meta data such as the Content-Encoding, Cache-Control, status codes, etc.

Along with these are also security headers that tell your browser how to behave when handling your website’s content. For example, by using the Strict-Transport-Security you can force the browser to communicate solely over HTTPS.

Since HTTP Headers have such an impact, We we will discuss few headers that can help you secure your apps by setting them :

1. Content security

Content Security Policy Helps to mitigate and detect threats like

a. Cross site scripting(XSS)

b. Data injection attacks

Therefore to enable CSP, we need to configure our web server to return the Content-Security-Policy HTTP header.

Content-Security-Policy: <policy-directive>; <policy-directive>

where <policy-directive> consists of: <directive> <value> with no internal punctuation.

example: The following policy has been set

default-src 'self';
// Serves as a fallback for the other fetch directives.
base-uri 'self';
// Restricts the URLs which can be used in a document's <base> element.
block-all-mixed-content;
//Prevents loading any assets using HTTP when the page is loaded using HTTPS.
font-src 'self' https: data:;
//Specifies valid sources for fonts loaded using @font-face.
frame-ancestors 'self';
//Specifies valid parents that may embed a page using <frame>,
 <iframe>, <object>, <embed>, or <applet>.
img-src 'self' data:;
//Specifies valid sources of images and favicons.
object-src 'none';
//Specifies valid sources for the <object>, <embed>, and <applet> elements.
script-src 'self';
//Specifies valid sources for JavaScript.
script-src-attr 'none';
//Specifies valid sources for inline styles applied to individual DOM elements.
style-src 'self' https: 'unsafe-inline';
// Specifies valid sources for stylesheets.
upgrade-insecure-requests
// Instructs user agents to treat all of a site's insecure URLs
 (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS). 

2. Expect-CT

When a site enables the Expect-CT header, they are requesting that the browser check that any certificate for that site appears in public CT logs.

Although browsers ignore the Expect-CT header over HTTP; the header only has effect on HTTPS connections.

maxAge is the number of seconds to expect Certificate Transparency. It defaults to 0.

enforce:  It implies that the user agent (usually a browser) should refuse future connections that violate its Certificate Transparency policy.

report-uri is a string. If set, complying user agents will report Certificate Transparency failures to this URL. Unset by default.

Expect-CT: report-uri="<uri>",
           enforce,
           max-age=<age>

3. Referrer-Policy

The Referrer-Policy HTTP header controls how much referrer information has been included with requests.

The Referer request header contains the address of the previous web page from which a link to the currently requested page was followed.

Referrer-Policy: no-referrer
Referrer-Policy: no-referrer-when-downgrade
Referrer-Policy: origin
Referrer-Policy: origin-when-cross-origin
Referrer-Policy: same-origin
Referrer-Policy: strict-origin
Referrer-Policy: strict-origin-when-cross-origin
Referrer-Policy: unsafe-url

4. HSTS

The HTTP Strict-Transport-Security response header (often abbreviated as HSTS) lets a web site tell browsers that it should only be accessed using HTTPS, instead of using HTTP.

max-age is the number of seconds browsers should remember to prefer HTTPS. It defaults to 15552000, which is 180 days.

includeSubDomains  dictates whether to include the includeSubDomains directive, which makes this policy extend to subdomains.

preload : it adds the preload directive, expressing intent to add your HSTS policy to browsers.

Strict-Transport-Security: max-age=<expire-time>
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains
Strict-Transport-Security: max-age=<expire-time>; preload

5. MIME sniffing

In the absence of a MIME type, or in certain cases where browsers believe they are incorrect, browsers may perform MIME sniffing — guessing the correct MIME type by looking at the bytes of the resource.

Each browser performs MIME sniffing differently and under different circumstances. (For example, Safari will look at the file extension in the URL if the sent MIME type is unsuitable.) There are security concerns as some MIME types represent executable content.

The X-Content-Type-Options response HTTP header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should not be changed and be followed. This is a way to opt out of MIME type sniffing, or, in other words, to say that the MIME types are deliberately configured.

X-Content-Type-Options: nosniff

6. X-DNS-Prefetch-Control

This response header controls DNS prefetching, a feature by which browsers proactively perform domain name resolution on both links that the user may choose to follow as well as URLs for items referenced by the document, including images, CSS, JavaScript, and so forth.

This prefetching is being performed in the background, so that the DNS is likely to have been resolved by the time the referenced items are needed. This reduces latency when the user clicks a link.

X-DNS-Prefetch-Control: on
X-DNS-Prefetch-Control: off

7. Disable client side caching

The performance of web sites and applications can be significantly improved by caching.

But in cases where the cached resource is confidential, caching can lead to vulnerabilities — and must be avoided. As an example, consider a web app that renders and caches a page with sensitive information and is being used on a shared PC. Anyone can view confidential information rendered by that web app simply by visiting the browser’s cache.

Cache-Control: must-revalidate
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: no-transform
Cache-Control: public
Cache-Control: private
Cache-Control: proxy-revalidate
Cache-Control: max-age=<seconds>
Cache-Control: s-maxage=<seconds>

8. X-Frame-Options

The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object>. Sites can use this to avoid click-jacking attacks, by ensuring that their content is not embedded into other sites.

X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN

DENY

The page cannot be displayed in a frame, regardless of the site attempting to do so.

SAMEORIGIN

The page can only be displayed in a frame on the same origin as the page itself.

9. X-Permitted-Cross-Domain-Policies

A cross-domain policy file is an XML document that grants a web client permission to handle data across domains.

When clients request content hosted on a particular source domain and that content makes requests directed towards a domain other than its own, the remote domain needs to host a cross-domain policy file that grants access to the source domain, allowing the client to continue the transaction.

Normally a meta-policy is declared in the master policy file, but for those who can’t write to the root directory, they can also declare a meta-policy using the 

X-Permitted-Cross-Domain-Policies HTTP response header.

10. X-Powered-By

X-Powered-By is set by various servers to say what kind of server it is.

When a web server/application is to be secured, be it PHP, Apache, Nginx, (whatever the software) the first thing to do is removing the web server/framework/etc. fingerprints if possible, i.e. the Server and X-Powered-By headers.