Appendix A: Requirements for HTTP Security Header

Modern web browsers support several additional client-side protection mechanisms that can be activated using HTTP response headers. The table below describes related requirements and recommendations for external Web UIs and services in production:

Headers that can be centrally included:

Response Header

General Requirement

For Web UI?

For APIs?

Content-Type

...; charset=utf-8

Yes

Yes

Strict-Transport-Security[1]

max-age=10886400; includeSubDomains; preload

Yes (if HTTPS)

Yes

X-XSS-Protection[2]

1; mode=block

Yes

No

X-Frame-Options

SAMEORIGIN

Yes

No

Referrer Policy

same-origin

Yes

No

X-Content-Type-Options[3]

nosniff

Yes

No

Headers that must be set within the Web application:

Response Header

General Requirement

For Web UI?

For APIs?

Set-Cookie

… ;httpOnly; secure; SameSite

Yes, when they transfer of confidential data in cookies

Yes, when they transfer of confidential data in cookies

Cache-Control

no-cache, no-store

Whenever confidential data is transmitted.

Whenever confidential data is transmitted.

Pragma

no-cache

Expires

-1

Content-Security-Policy[4]

object-src 'none'; script-src ‘self’ [URL1] [URL2]; style-src ‘self’ unsafe-inline; object-src ‘self‘;base-uri 'none';

General recommendation for new for all Web UIs. Not required for APIs.

No (but does no harm if yes)

object-src 'none';
script-src 'nonce-{random}' 'unsafe-inline' 'unsafe-eval' 'strict-dynamic' https: http:;
base-uri 'none';
report-uri https://your-report-collector.example.com/

Recommendation for new Web UIs that have to use inline script blocks (e.g. if integrated by a JS framework).

Do not use this setting if you do not have to since it disables CSP protection for older browsers!

No

Content-Disposition

attachment; filename=<filename>

Web UIs  at which users can download files that are potentially untrusted.

No

X-Download-Options

noopen

No

Caution: Settings these headers may have implications on the proper functionality of a web application. Therefore, activating a new header SHOULD always be combined with comprehensive functional tests.


[1] HTTP Strict Transport Security (HSTS) forces users of a web site to exclusively access it via HTTPS for a defined amount of time. Before using this header, you should ensure that all requests to this host (and to all subdomains when using includeSubDomains attribute) can be executed using HTTPS. This header prevents certain man-in-the-middle attacks.

[2] Additional Cross-site Scripting prevention (IE only).

[3] Deactivation of MIME sniffing in browsers that are used to identify MIME types but also to execute certain Cross-site Scripting attacks.

[4] A Content Security Policy (CSP) provides an additional but very effective client-side protection against many common client-site attacks such as Cross-site Scripting (XSS). Applications must explicitly support it which often requires a CSP compliant MVC framework. For more on practical CSP recommendations have a look at https://csp.withgoogle.com/docs/strict-csp.html.