How to Implement HTTP Security Headers to Protect Your Website

7 mins
23 Aug 2022

Security or security on the website is very important and has a wide scope, like riding a bicycle, where to be able to balance the bicycle, you have to move and keep the bike running, you can't stop pedaling or your bike will start to slow down and roll over, you definitely don't want it. that's not it?

Let's talk about HTTP security headers on websites, what are they? HTTP security headers are the basis of security that serves to protect against various types of attacks such as XSS (Cross Site Scripting), code injection, clickjacking and so on.

When a user visits a website with a browser, the server will respond to metadata from HTTP headers, some of these headers will tell the browser to parse the data while communicating with the website meta data.

And also you can use some additional security meta data in HTTP headers to safely parse communication into the browser, what are the website security HTTP headers from that meta data?


How to implement HTTP Security Headers to protect your website



1. HTTP Strict Transport Security (HSTS)

Say you have a domain with the name and you have installed an SSL certificate and migrated from HTTP to HTTPS, this is something that should be done right? The question is, what if your website can still be accessed using HTTP? hmm .. you can say yes it's just not safe.

Some webmasters who migrate their websites from HTTP to HTTPS are not aware of this. By enabling HSTS, the server will force the browser to communicate with HTTPS and most likely communicate with the HTTP protocol will be eliminated.

Example for enabling HTTP Strict Transport Security in .htaccess:

Header set Strict-Transport-Security "max-age=31536000; includeSubDomains;"


2. Content Security Policy

Content Security Policy serves to provide full control to limit some resources such as CSS, JS, inline javascript or other assets that can only be used by site admins on the website.

It's like with this Content Security Policy, all assets will be whitelisted, and assets that are not granted access rights will not work and must be whitelisted first.

This Content Security Policy protects against all Cross Site Scripting attacks and code injection attacks, although it can't be completely eliminated, but it can certainly minimize damage to the website. All types of browsers currently support CSP3 such as Mozilla, Chrome, Edge etc. Example to enable Content Security Policy in .htaccess:

Header set Content-Security-Policy "default-src 'self'; script-src 'self'; img-src ' self' *;"


3. X Frame Options

There is a term clickjacking type attack, this attack technique is to trick the user into clicking something that is not actually there, the user thinks he is already on the official website, but actually it is just a trick of the hacker and there is something going on behind the scenes that the user is not aware of.

The danger is, the victim's personal identity can be stolen in the clickjacking site page, such as email and passwords. To prevent this, additional HTTP headers are needed, namely X-Frame-Options, X Frame Options serves to guard against clickjacking-like attacks by disabling iFrames or Objects on the website. IFrames or Objects are usually used by hackers to manipulate sites as if they are legitimate.

By activating X Frame Options, the site does not allow other people or anyone to insert content such as iframes or objects into the content.

Example to enable X Frame Options in .htaccess:

Header set X-Frame-Options SAMEORIGIN


4. Cross Site Scripting Protection (X-XSS Protection)

As the name implies, X-XSS Protection functions to protect against Cross Site Scripting attacks. XSS filter is enabled by default in browsers like Chrome, Safari and Edge.

If the XSS Filter is active, the browser does not let the page load when it detects an attack from Cross Site Scripting.

Example to enable X-XSS Protection in .htaccess:

Header set X-XSS-Protection "1; mode=block"


5. X Content Type Options

X Content Type Options is a component of the HTTP header that responds to MIME (Multipurpose Internet Mail Extensions) which is used to secure data from possible sniffing.

The MIME example is like a jpg image format that has a MIME image/jpeg or a png image that has a MIME image/png. Then what is sniffing? sniffing itself is an activity to monitor all content that occurs in network traffic.

Example to enable X Content Type Options in .htaccess:

Header set X-Content-Type-Options nosniff


6. Feature Policy

What is HTTP header Feature Policy? Feature Policy is a meta data in the HTTP Header that allows what features the browser allows to load. Today many technologies make it possible to add features that help from the user's side, but this has an impact on site security.

Like Geolocation, the technology can tell where visitors are coming from. If we talk about profit, it actually benefits us, right? can monitor users and map them.

But there is another thing that is more important, namely GDPR, where the rules are not allowed to store data or in the form of cookies and others. Although these rules apply in Europe, what if users from Europe visit our website.

There is another thing that is far more dangerous, namely what if the user secretly activates the camera or microphone feature? well with this Feature Policy, we can set the browser to disable the features mentioned earlier.

Example to enable Feature Policy in .htaccess:

Header set Feature-Policy "microphone 'none'; camera 'none';


7. Referrer Policy

Referrer Policy is a policy that is applied when a user navigates through a link on the website. In some cases, sites need to protect users' privacy when they click on external links.

This is very important to protect if the link comes from banking, e-commerce that does not implement the HTTP protocol. It is very risky to be hacked, because other people can find out where the source comes from that triggers clicks into the website without any settings in the referrer policy.

Some options in Referrer Policy:


The No-referrer option will remove the referrer header, the request information sent does not include anything.


Send the origin, path and query string to the referrer when the protocol is the same or increased as HTTP→HTTP, HTTP→HTTPS, HTTPS→HTTPS. This option will not send referrer headers when requests to less secure destinations such as HTTPS→HTTP, HTTPS→File protocols.


Only send from the origin of the referrer header, meaning that it only sends domain information and does not use the full path, for example the domain, will send the referrer to


This option, will send the full path if the user clicks on an internal link on the website where the query string, path, and origin domain go through the request in the same protocol level as (HTTP→HTTP, HTTPS→HTTPS)


The information sent is the full path on the internal link on the website and provides a no-referrer on the external link.


Domain information will be sent using the protocol (HTTPS→HTTPS, HTTP→HTTP), and will not downgrade to a less secure protocol (HTTPS→HTTP) .


Sends the full path URL on the domain, and the domain on the external link is a secure protocol (HTTPS→HTTPS) and will not send a referrer if it goes through an insecure protocol (HTTPS→HTTP).


Sending the full path under any conditions, be it safe or not.

Referrer Policy can be integrated using HTML tags with meta documents:

<meta name="referrer" content="origin">



It is very important to secure the website from any hacker attacks, this is to keep users comfortable when browsing your web pages. You can check your website's HTTP Header with the help of the online HTTP Security Header Checker tool to monitor your website's HTTP Header regularly.

HTTP Security headers are a fundamental method of site security, which it is very important to understand and implement into your website application projects so that they are always safe and secure.