Oracle recommends that you set the values of the HTTP headers listed in this section to prevent exploitation of known vulnerabilities caused due to these headers not being set, or set with wrong/default values.
The following are some of the commonly used secure headers:
- Headers to Mitigate XSS Attacks
- HTTP Strict Transport Security Header
- X-Frame-Options Header to Mitigate Clickjacking Attempts
- Secure Flag for Cookies
- SameSite Flag for Cookies
Note:Best practice is to set these headers at the application level. If it is not possible or if you want to exercise extra precaution, you can configure them in Oracle HTTP Server. See My Oracle Support document ID 2370975.1.
Headers to Mitigate XSS Attacks
Cross-Site Scripting (XSS) attacks occur when an attacker sends malicious code to a different end user through a web application, in the form of a browser side script. Faults in web applications allows XSS attacks to succeed and can occur wherever a web application uses input from a user without validating or encoding it.
For example, an attacker may use XSS to send a malicious script to an user. Unaware of the situation, the end user’s browser might execute the script assuming that the script is from a trusted source and might let the malicious script to access cookies, session tokens, or other sensitive information retained by the browser and used with that site.
Content Security Policy
A Content Security Policy header helps to mitigate the risk of content injection by giving developers control over resources that can be requested on behalf of a worker.
It is not possible for the web server to implement Content Security Policy because the web server does not know the list of domains from which an end-user’s web application is allowed to load style sheets, images and so on. The web server also does not know if the application makes use of plugins, media, and so on and if these are to be allowed to be loaded.
Oracle recommends that a policy based on the application characteristics be defined and implemented using the Content Security Policy header.
The following are examples to use Content Security Policy rules:
Content-Security-Policy: default-src 'self'
- All resources are hosted by the same domain of the given page.
- There are no inlines or evaluationss for scripts and style resources.
Content-Security-Policy: default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';
- Does not allow resources like object, frame, and media to load.
- Allows images, scripts, AJAX, and CSS from the same origin.
Content-Security-Policy: frame-ancestors self;
Note:The X-XSS-Protection header has been deprecated by modern browsers and its use can introduce additional security issues on the client side. Therefore, Oracle recommends you to set the header as X-XSS-Protection: 0 to disable the XSS Auditor, and not allow it to take the default behavior of the browser handling the response. Use Content-Security-Policy instead. See Content Security Policy.
The X-XSS-Protection header re-enables the XSS filter for a particular website, if the user has disabled it. It is a security best practice to include the X-XSS-Protection header in all HTTP responses.
Table 3-1 describes the X-XSS-Protection header values.
Table 3-1 Header Values and Descriptions
If a cross-site site scripting attack is detected the browser sanitizes the page to stop the attack.
The browser prevents rendering of the page.
The browser sanitizes the page and reports the violation.
- Open the
httpd.conffile using the Advanced Server Configuration page in Fusion Middleware Control or a text editor.
- Add the following header configuration, after the
<IfModule mod_headers.c> Header set X-XSS-Protection "1; mode=block" </IfModule>
Setting the header does not guarantee that these attacks will be prevented. You may want to consider other best practices as well.
HttpOnly is an additional flag included in a Set-Cookie HTTP response header, which helps to mitigate the risk of client side script accessing the protected cookie.
HttpOnly flag is included in the HTTP response header, the cookie
cannot be accessed through client side script (if the browser supports this flag). As a
result, even if a cross-site scripting (XSS) flaw exists, and a user accidentally
accesses a link that exploits this flaw, the browser will not reveal the cookie to a
<IfModule mod_headers.c> Header edit Set-Cookie ^(?!IGNOREME=).*$ $0;HttpOnly;secure </IfModule>
above configuration example provides a mechanism to specify that certain cookies should
not have the
HttpOnly flag set. If a particular cookie is not a
candidate for the
HttpOnly attribute, then replace the string
IGNOREME with the cookie name in the configuration above.
To avoid the
HttpOnly flag from being added to the response
cookie called MYCOOKIE1, run the following command to replace
Header edit Set-Cookie ^(?!MYCOOKIE1).*$ $0;HttpOnly;
To exclude multiple cookies, run the following command:
Header edit Set-Cookie ^(?!(IGNOREME=|IGNOREME1=)).*$ $0;HttpOnly;
HTTP Strict Transport Security Header
HTTP Strict Transport Security (HSTS) is a security enhancement in which a browser always connects to the site returning the HSTS headers over SSL/TLS, with-in a specific duration set in the header. All connections to the server over HTTP is automatically replaced with HTTPS, even if the user uses HTTP in the URL. HSTS header also prevents HTTPS click through prompts on browsers.
To enable HSTS policy header, add the following to your SSL enabled virtual host:
<VirtualHost example.com:4443> Header always set Strict-Transport-Security "max-age=63072000; preload; includeSubDomains" </VirtualHost>
The Referrer-Policy header contains the address of the previous web page that a user follows to accesses the currently requested page.
The Referrer-Policy header has many uses including analytics, logging, optimized caching, and more problematic uses such as tracking, or stealing information. It also has side effects such as inadvertent leaking of sensitive information.
To enable Referrer-Policy, set the Referrer-Policy header to:
Header always set Referrer-Policy "same-origin"
This ensures that a referrer is sent for same-site origins, and the cross-origin requests does not contain referrer information.
X-Frame-Options Header to Mitigate Clickjacking Attempts
Note:The CSP frame-ancestors obsolete the X-Frame-Options header. If a resource has both policies, the CSP frame-ancestors policy is enforced and the X-Frame-Options policy is ignored.
X-Frame-Options is a server-side method of combating clickjacking.
Clickjacking, also known as a UI redress attack, is a method in which an attacker uses multiple, transparent or opaque layers to trick a user into clicking a button or link on a page, other than the one they believe they are clicking.
To enable X-Frame-Options, set the X-Frame-Options header to:
Header setifempty X-Frame-Options SAMEORIGIN
The X-Content-Type-Options header is a response HTTP header used by the server to protect against MIME sniffing vulnerabilities.
MIME sniffing is used by browsers to determine an asset’s file format, when there is not enough metadata information for a particular asset.
The lack of X-Content-Type-Options header in response causes certain browsers to determine the content type and encoding of the response even when these properties are defined correctly. This can make the web application vulnerable to Cross-Site Scripting (XSS) attacks.
For example, some versions of Internet Explorer and Safari browsers treat
responses with the content-type
text/plain as HTML if they contain HTML tags.
To set the X-Content-Type-Options header, make the following change in all responses which contain user input:
<IfModule mod_headers.c> Header always set X-Content-Type-Options nosniff </IfModule>
ServerSignature directive allows you to configure a footer in the web server generated documents.
In a chain of proxies, the footer tells which of the chained servers produced a returned error message. The syntax is:
ServerSignature On | Off | EMail
The default value is
Off, which suppresses the footer line. The value
On adds a footer with the server version number and the server name of the serving virtual host. The value
mailto: reference to the value specified in the
ServerAdmin directive of the referenced document.
ServerTokens directive allows you to configure the server HTTP response header.
This directive controls whether the server response header field which is sent back to the clients includes a description of the generic OS-type of the server as well as the information about compiled-in modules. The syntax is:
ServerTokens Full | OS | Minor | Minimal | Major | Prod | None | Custom
The default value is
Full, which includes information about the OS-type of the server and the compiled-in modules. The value
Prod includes the least information. The value
None removes the server header. The value
custom takes a string as a second argument, which is used as the value of the server header.
You can use
ServerTokens Custom some-server-string to disguise the web server software when Oracle HTTP Server generates the response header. When a backend server generates the response, the server response header may come from the backend server depending on the proxy mechanism.
ServerTokens Custom some-server-stringis a replacement for the
ServerHeader Offsetting in Oracle HTTP Server 10g.
Secure Flag for Cookies
The secure flag is an option that can be set when sending a new cookie to the user within an HTTP Response. The purpose of the secure flag is to prevent cookies from being transmitted in clear text. When the secure attribute is associated with a cookie, browsers will not transmit such cookies over clear-text, thus preventing unauthorized parties from accessing the cookie.
<IfModule mod_headers.c> Header edit Set-Cookie ^(.*)$ $1; Secure; </IfModule>
SameSite Flag for Cookies
SameSite attribute of the
Set-Cookie HTTP response header allows you to declare if your cookie should be restricted to a first-party or same-site context.
SameSite attribute accepts three values. The Syntax is:
SameSite=Lax | Strict | None
Lax: Cookies are not sent on normal cross-site sub-requests (for example, to load images or frames into a third party site), but are sent when a user navigates to the origin site (that is, when following a link).
This is the default cookie value if the
SameSiteattribute is not set explicitly. This ensures that users have reasonably robust defense against some classes of cross-site request forgery (CSRF) attacks.
Strict: Cookies are sent in a first party context and not along with the requests initiated by the third party websites.
None: Cookies are sent in all contexts, that is, in responses to both first-party and cross-origin requests. If you set
SameSite=None, then you must also set the cookie
Secureattribute. If you don't, the cookie will be blocked.