Site Server Security, SEO, and You: Get Cozy with your WebDevs
It’s very easy for digital marketers to become separated from the IT team/WebDevs when making site improvements. Schedules get hectic, there’s organizational silos slowing you down, or maybe you simply never talk to each other. Many organizations leverage cross departmental collaboration solutions to prevent this, but even in those, it can be easy to forget about site security and how it affects SEO. Poor security can lead to increases in page load time, down time, and potential malicious assets or redirects being snuck onto your site. In order to provide the best User Experience, it’s imperative that your site remains secure, even if you never touch credit cards and other PCI info or PII.
Creating a website that leverages HTTPS is, frankly, becoming the norm, so we won’t get into that. If you want to learn about HTTPS, OnCrawl has a great article about how HTTPS improves your SEO specifically, but there are some secondary site security topics that might not be as obvious and could be potential gains for you, your clients, and your organization.
Ideally, getting these fixes implemented will prevent attacks on your site, improve site speed, up-time, and more, with the added bonus of creating a good workflow and relationship with your Dev team! My opinion is always that Marketing and Development should work together whenever possible to create the best user experience for customers.
Let’s start with the most common security issue, and user privacy complaint: Cookies
You can, in theory, load any number of cookies (preferably from trusted sources and that are themselves secure) but while it’s smart to limit the number of cookies leveraged, you should also make sure that your cookies as set with a “secure” flag.
For instance, in ASP.NET, all you have to do is set the following in Web.config: <httpCookies requireSSL=”true” /> or set the requireSSL=”true” flag in the web.config for specific page elements. Very simple!
In PHP, you can set the flag permanently in php.ini by setting session.cookie_secure = True as the parameter.
There’s a LOT of information out there on securing cookies and different languages, so I would suggest you go to Plural Sight for more specific information that you might find helpful for YOUR site if you’re using something besides ASP.NET or PHP.
Server Software Headers:
Every site runs on a server (duh) but did you know that your site server itself might be specifically telling attackers how to find exploits for your system? Server headers publicly display what type of server you use, its version number, content type and what software it is running. You can shut off/stop sending your server header in a few ways, depending on your technology.
ngnix: You can adjust the content that nginx sends by editing nginx.conf. First, find the http section, which is what defines the HttpCoreModule configuration. Next to turn off the header info, all you have to do is add thhis: server_tokens off; as a directive.
IIS, the Windows Server platform, is a little more complicated, and involves getting some resources directly from Microsoft. It can be a little frustrating, but it’s worth it.
Step one is to enable “Metabase Compatibility” (which you can do by following these instructions from Microsoft.)
Next, you’ll install the URLScan resource (also found on Microsoft’s support site)
Once that’s done, open the URLScan.ini file with a text editor and search for the key “RemoveServerHeader”. This is set to 0 by default which allows for the header to be sent, so just set the value to 1 to stop sending the server header.
Apache/Lighttpd: Unfortunately, I don’t have enough experience on Apache or Lighttpd to be able to provide a guide on how to adjust those, but I encourage you to work with your dev team to resolve that if you’re using either of them.
Now we get into the specific security headers. So, there are some security headers besides the ones I’m going to get into below, but the following are the ones that I SPECIFICALLY have experience with. I HIGHLY advise you to do an audit of your server security headers with your Dev team (preferably over donuts and coffee), because they probably know of more than I do, and you can work on implementing solutions together.
Public-Key-Pins:
HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised. To start leveraging these benefits, you need to set the following header “pin-sha256=”base64==”; max-age=expireTime [; includeSubDomains][; report-uri=”reportURI”]” You’ll also find it useful to look up software specific implementation for Apache, Lighttpd, and IIS to maximize compatibility.
Strict-Transport-Security:
HTTP Strict Transport Security strengthens your implementation of TLS by getting the user agent to enforce the use of HTTPS. (I know, I know. I HAD to include SOMETHING about HTTPS!)
It protects against protocol downgrade attacks and also creates another layer of cookie security by preventing hijacking.
While there’s some…grey area…around some people using this feature to create ‘Supercookies’ that can push through browser ‘incognito’ and ‘hidden’ sessions, I still personally find this a valuable addition for server security. If you are cool about it, your users will thank you.
I recommend using the following value: “strict-transport-security: max-age=31536000; includeSubdomains”.
Content-Security-Policy:
This is a great way to protect your site from XSS attacks. When you whitelist approved content sources, you can prevent browsers from loading malicious assets, which may have been inserted without your permission, that cause security issues for your users and your host server. To tell your server to only allow assets hosted by your site (or a trusted 3rd party) you just adjust your Content-Security-Policy header to read: Content-Security-Policy script-src ‘self’ YOURDOMAIN.com. Simply append the serving domain of your 3rd party assets after your own to include those too.
Quick note! If your header still reads X-Content-Security-Policy, you should update that, since browsers now primarily support the unprefixed version. You can find other tutorials that show you ALL of the supported policies and variables you can include here, but this is the most basic one to whitelist your own resources.
X-Content-Type-Options:
X-Content-Type-Options stops a browser from trying to MIME-sniff content types. Crazy simple. As an added bonus, it forces a browser to resolve only the declared content types. There’s actually only one valid value for this header that I’m aware of, and that’s “X-Content-Type-Options: nosniff”.
X-Frame-Options:
The X-Frame-Options header informs the browser whether you want to allow your site to be framed or not. If you keep a browser from framing your site, you can prevent “clickjacking.” You should set this to read “x-frame-options: SAMEORIGIN”.
X-XSS-Protection:
This header sets the configuration for cross-site scripting filters built into most browsers, excluding nonsupported IE versions, and Netscape. But who uses Netscape anymore, honestly? The recommended value for this header is “X-XSS-Protection: 1; mode=block”.
The process of getting these fixes implemented should only take a few days total, including the audit, but once done, you can rest easier knowing that your site server is more secure and that your users are protected from exploits. Plus, hopefully you’ve gotten closer to your Dev team, and built a good relationship to better serve your organization overall!
