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:
...
Response Header | General Requirement | When? |
Content-Type |
| always |
Strict-Transport-Security[1] |
| For all Web UIs that are only accessible via HTTPS |
X-XSS-Protection[2] |
| For all Web UIs. Not required for APIs. |
X-Frame-Options |
| For all Web UIs. Not required for APIs. |
Referrer Policy |
| For all Web UIs. Not required for APIs. |
X-Content-Type-Options[3] |
| For all Web UIs. Not required for APIs. |
Headers that must be set within the Web application:
Response Header | General Requirement | When? |
Set-Cookie |
| Web UIs that transfer of confidential data in cookies |
Cache-Control |
| Whenever confidential data is transmitted. |
Pragma |
| |
Expires |
| |
Content-Security-Policy[4] |
| General recommendation for new for all Web UIs. Not required for APIs. |
| 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! | |
Content-Disposition |
| Web UIs at which users can download files that are potentially untrusted. |
X-Download-Options |
|
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.
...