Learn how a brain-based behavioral health center is expanding its local reach online to increase patient consultations despite a limited physical footprint.
HTTP security headers can make an SEO impact — but are they necessary? Learn about the top 5 HTTP headers and how they fit into the GPO product.
Website security headers are a set of rules you establish for your website to follow. They are small pieces of information that your website sends along with its web pages when someone visits it in order to make your website more secure and less vulnerable to cyberattacks, automated bot software, and malicious activities.
Think of these security headers as signs you put up around your house. Each sign tells visitors and potential intruders certain things about how to behave when they’re on your property.
Five security headers are considered important for SEO:
A site may use a 301 redirect to direct users from HTTP to HTTPS. However, hackers could potentially reverse this redirect and use the less secure HTTP site to gather sensitive information. The HTTP Strict Transport Security header (HSTS) ensures that attackers cannot downgrade the site from HTTPS to HTTP by forcing the browser to only accept HTTPS connections. This significantly enhances security by maintaining a consistent and secure browsing experience for users.
The Content-Security-Policy header is a set of rules that informs visitors where your site can retrieve content from and specifies sources from which it cannot load content. Beyond preventing hackers from uploading malicious scripts (Cross-Site Scripting or XSS) or data injections that could exploit the site, CSP also helps thwart clickjacking attacks by controlling which domains can embed your content. Additionally, CSP can mitigate potential security risks by limiting resource loading to trusted sources, ultimately enhancing overall web security.
Sometimes, browsers might interpret a data file as something unintended due to a feature called content type sniffing. For instance, a “.txt” file containing HTML code might be misinterpreted. Hackers can exploit this behavior by uploading malicious files that, when downloaded, can execute harmful actions.
To counter this, the X-Content-Type-Options header prevents browsers from engaging in content type sniffing. By doing so, it safeguards against potential vulnerabilities by enforcing the declared file type and discouraging browsers from guessing the type based on the file’s content.
When you navigate from one page to another, your browser can reveal where you came from, forming a digital breadcrumb trail. A Referrer-Policy Header lets you dictate how much of this information you’re willing to share as users move across pages. With eight different directives, this header allows you to fine-tune the information sharing process:
Attackers can attempt to exploit your website’s content by embedding it within their own site, potentially leading to security vulnerabilities. For instance, an attacker might embed an image from your site on theirs. While the act of embedding isn’t directly malicious, attackers might use CSS and JavaScript to manipulate the content’s appearance, potentially leading to malicious interactions.
The X-Frame-Options Header is a security feature designed to protect your website from being displayed within a frame or iframe on another site. This defense mechanism aims to prevent clickjacking attacks, where attackers try to trick users into interacting with your content in unintended ways by overlaying it with deceptive elements. By employing the X-Frame-Options Header, your site maintains control over how and where your content is displayed, contributing to a more secure online environment.
Why don’t we use it? At GPO, our current practice involves forcing all HTTP resources to redirect to HTTPS. Additionally, we do not implement any cookies in order to protect, so the added security provided by HSTS is not an immediate necessity.
What benefits do we gain from not using it? By abstaining from HSTS, we avoid the complexity and resource investment required for its implementation. Our existing practice of HTTP to HTTPS redirection already offers a substantial level of security for our web services.
What do we do instead? Instead of implementing HSTS, we prioritize the enforcement of HTTP to HTTPS redirection as our primary security measure.
Why don’t we use it? GPO does not implement CSP due to the potential for it to block third-party scripts and widgets, such as Google Tag Manager (GTM), which are essential for the proper functionality of our client sites.
What benefits do we gain from not using it? By refraining from CSP, we prevent potential disruptions to the functionality of client sites, especially those relying on third-party services.
What do we do instead? Instead of implementing CSP, GPO can consider crafting a customized CSP policy that allows specific domains and sources necessary for our sites to function properly. GPO can initiate CSP in report-only mode to monitor violations without blocking resources, enabling us to fine-tune the policy based on violation reports.
Why don’t we use it? GPO has opted not to implement the X-Content-Type-Options header because we do not allow file uploads, thereby eliminating any associated risk.
What benefits do we gain from not using it? Omitting the X-Content-Type-Options header is driven by the fact that it is not relevant to our current operations, and it allows us to invest resources in more applicable features.
What do we do instead? Since we do not allow file uploads, there is no need to take any specific actions regarding the X-Content-Type-Options header.
Why don’t we use it? GPO refrains from implementing a strict Referrer-Policy because of the potential to break functionality, particularly affecting analytics and tracking.
What benefits do we gain from not using it? By maintaining a more permissive default Referrer-Policy, we avoid potential disruptions to the functionality of client sites, especially concerning analytics and tracking. This approach also eliminates the need for extensive communication with clients to tailor the policy to their individual privacy requirements.
What do we do instead? Currently, we set the default policy to “strict-origin-when-cross-origin,” with subdomains excluded for heightened cross-origin security, and only consider making it stricter upon specific client requests, which necessitate client communication to understand their privacy requirements.
Why don’t we use it? We choose not to utilize the X-Frame-Options header because it provides a binary choice – allow or deny embedding. This limits our flexibility in controlling the embedding of our content, which we prefer not to restrict.
What benefits do we gain from not using it? By refraining from the X-Frame-Options header, we retain the flexibility to allow embedding of our content as needed, without imposing strict restrictions.
What do we do instead? Instead of relying on X-Frame-Options, we allow embedding as required, and when necessary, we put in the effort required for configuration and testing to ensure it aligns with our needs and the specific requirements of the client.
Learn how a brain-based behavioral health center is expanding its local reach online to increase patient consultations despite a limited physical footprint.
Your seasonal content is looking a little dusty. Is it time for a quick refresh, or do you need to start from scratch?
SEO will still have a place in an AI future. Make sure your brand is prepared.