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:
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 .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.
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.
The Content Security Policy is a browser side mechanism which allows you to create source whitelists such as JavaScript, CSS, images, and so on, for client side resources of your web application. The Content Security Policy instructs the browser through a special HTTP header, to only execute or render resources from those sources.
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'
Content-Security-Policy: default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src '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.
This enables browser detection of reflected XSS attacks. Underlying reflected XSS vulnerabilities still need to be fixed in the underlying application. A browser detecting an XSS and blocking it does not mean that the application has an XSS vulnerability. In some cases, this header may block legitimate responses, for example, a message board where javascript programming is discussed.
Table 3-1 describes the X-XSS-Protection header values.
Table 3-1 Header Values and Descriptions
httpd.conf
file using the Advanced Server
Configuration page in Fusion Middleware Control or a text editor.
LoadModule
section:
<IfModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
</IfModule>
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.
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>
The
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
EMail
additionally creates a
mailto:
reference to the value specified in the
ServerAdmin
directive of the referenced document.
The
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.
Note:
ServerTokens Custom
some-server-string
is a replacement for the
ServerHeader Off
setting in Oracle HTTP Server 10g.
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.
Example configuration:
<IfModule mod_headers.c> Header edit Set-Cookie ^(.*)$ $1; Secure; </IfModule>
The
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.
The
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
SameSite
attribute 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
Secure
attribute. If you don't, the cookie will be blocked.