HTTP Security Headers & Redirects Without a Plugin | xCloud Site Rules

I'd like to talk to you about site rules on xCloud hosting. We'll talk a little bit about what they are, how to set them, how to remove them, and where you can learn more, because you should learn more. It's good stuff. Let's get started. I'm here on the admin panel for a single site, cybernate360.com, and in the left column under Tools, I'm on Site Rules. And you can set up 2 kinds of site rules, headers and redirects. Now, a header rule can be something like X-Frame-Options header, which dictates if your page, your site can be embedded as an iframe somewhere else. There's also a permissions policy header, referrer policy header, and there's more. I'll show you what they look like and how they work. But you can also do redirects, which are exactly what they sound like. You choose the old place and the new place, and people get sent there. Now, before I show you how to use them, I want to point out a couple things. There's some excellent documentation here on how to set them up. It's very technical, and it does not discuss whether you should set them up or why you want to. It's just how to do it. If you want to know more about whether you should set them up and implications for SEO and performance and all that kind of stuff, we also have this piece of documentation, which is really, really good. It does tell you a bit how to set them up, but it tells you what they are, what they do, why they matter, and things like that. So I recommend you check this one out especially. Now, I did a quick curl request for CyberKnife 360, and these are the headers that came back. There's my content-type server, vary-link, X-Cache, so it hit the cache. There's X-Frame-Options, so this one's already set for same-origin. Uh, XSS protection, content-type options, uh, there's a whole bunch of stuff here. But you can go to securityheaders.com and do a scan, and it tells you what security headers are set and what aren't. So Cybernate is missing 4, but it has 2. And you'll note that we haven't set any up yet. So the question is, why do we already have 2? Well, headers can come from a variety of places. A WordPress plugin like Wordfence or something could be setting this. Uh, Sucuri, um, SEO plugins will set them sometimes. There's a lot of places these can come from. And so you don't necessarily need to go in and set up every single one yourself. Use this site to check to see what is already set. So the first one we're going to check out is Strict Transport Security. And before you set any of these, you should research what they mean, what they do, etc. So let's check out Strict Transport Security header. So this informs browsers that the host should only be accessed using HTTPS. And that any future attempts to access it using HTTP should automatically be upgraded to HTTPS. So this similar to a force HTTPS plugin, but done on the server level rather than a plugin level. Additionally, on future connections to the host, the browser will not allow the user to bypass security connection errors such as an invalid certificate. So I get this a lot working locally. I'll set up a local server. SSL is weird. I can say, go ahead and accept it anyway. And that's totally fine using my own local server. But if I connect to a respected site online and it says, oh no, your SSL certificate is wrong, I don't want to be able to click okay anyway and go through. So Here are some options. You can set a max age, include subdomains, and the preload option. And there's a lot of information here that you can check out. But let's go see what options we have. I'm going to click header rules. Then these are our options for headers predefined. But you'll note there's a custom one. You can make up headers and actually people do it all the time. It's perfectly normal. Um, for a variety of reasons. You should research that yourself. But, um, let's go to Strict Transport Security. Uh, we're going to set it. There's the header, and here are the defaults. Boy, that's in milliseconds. Let's see how long that is. That is 1 year. All right, so we're going to set this policy for a year. Include subdomains. Now, before you just turn it on, you should test it. So we're going to test this rule and it passed. So now we will save this rule and there we go. We have one here and you'll see that we can edit it or delete it right there. I want to point out before I go run the test again that you're only allowed 10 header rules. If you get too many, it can impact performance and stuff like that. So if you find yourself needing more than 10 header rules, you should do some strategic rethinking and Decide whether those are really important. Redirects, you can do up to 25. We'll talk about that number in a few minutes. But for right now, let's go scan this again. There we go. We have a strict transport security policy. Let's look at content security policy. That one is here. And this one can get a little complicated. This is about what you allow to run on your site. So for example, here's a common one: default source self, image source self, example.com. And this says the first directive tells the browser to load only resources that are same origin with the document. So you can't load an image from another server unless other more specific directives say something differently. The second image source tells the browser to load images that are same origin or that are served from example.com. So this allows you to say your images only from the same server or that other server, which could be a CDN. So but that kind of thing also prevents things like these scripts running from another server. All of this kind of stuff can no longer work. So this is a great header to send. So let's set that up. Content Security Policy. So we have default source is self, script source is self, object is none. So you can't run an object. Uh, I haven't seen an object in a long time. Java used to do that. Uh, base URI is self and frame ancestors none. And I'm going to test this rule. Now, keep in mind, these are just the default suggestions. Um, I recommend taking the time to learn about what these options are, what other options you have and craft something that is suitable for your site. So that passed. Let's save that rule and we will run our scan again. There we go. Now we have an A, but there are still a couple more to go. So let's look at referrer policy. And this dictates how much information your server sends to the browser about the referrer, where it came from. And so you could say no referrer, don't tell them where it came from. Actually, it's not to the browser, it's to the other website. So if you click on my website and go to some other website, that other website knows where you came from, came from my site. But you could say no, don't tell that, or don't tell when you downgrade from HTTPS to HTTP, only send it from the origin or cross-origin. There's a lot of options here. So let's set that one up. And we do strict-origin-when-cross-origin. So let's see what that one is. There we go. Send the origin path and query string when performing a same-origin request. For cross-origin, send only the origin when the protocol security level stays the same. Don't send the referrer header to less secure destinations. So I'm going to hit test on that one. That one passed. So now we will save. And the last one was permissions policy. I like this one. It's cool. Um, sadly it's not supported by Firefox or Safari. So, uh, you can set it and it will take effect for the right browsers, but not for everybody. But this allows you to say what kinds of things, uh, the site can use on The— well, it's a lot of things. Um, so there's an allow list. What are things— what things are allowed? And there's a report too. So you can dictate whether or not the, the page can use the accelerometer in a mobile device or the ambient light sensor, uh, or autoplay or Bluetooth or camera or all this stuff. All this stuff you can say Uh, with the permissions policy header. So let's turn that one on and see what the defaults are. So we have geolocation, microphone, and camera, and they're set, but there's nothing in here. So this one can get a little complicated. You saw how many things there are, and then within each thing you can say what happens to that thing, and it only works on a couple browsers. So whether you set this up is up to you. It can be quite powerful, especially if you have control over the browser, you're serving a limited community or something. So let's test this rule. There we go, our configuration passed and save. And once it is saved, we will scan again. There we are, they are all set. Now let's come back over here and rerun it. Here and see if we see the difference. We do. There's the permission policy and the referrer policy, strict transport, content security, et cetera. So that's a little bit about what kinds of headers you can set as well as how to set them. But let's also look at redirect rules. Now, there's a very common plugin in WordPress called Redirection, which allows you to set up redirects and you can set up hundreds or even thousands of them. This only allows 25. If you need more than 25, then maybe this isn't the right tool. If you need fewer than 25, then this is exactly the right tool. And the reason is that a plugin like Redirection uses both PHP and NGINX resources and MySQL and just takes a lot of resources to do its thing. And when you end up with thousands of redirections, then there's a ton of time there. Looking at stuff. If you do it in something like this, then it happens before it ever hits the web server and none of that gets spun up. You save all those resources, all that time. This is— if you need fewer than 25, this is absolutely the way to go. So let's add a rule. So there's 2 kinds of redirections, permanent and temporary, and you need to think carefully about which one you use. Is if you do a permanent redirection on a URL that you think you might bring back someday, that's very sad because Google will not come back because you told it, nope, this is gone forever. Whereas a temporary redirect, you can send away someplace for a little while and then bring it back. So let's do a temporary. And here you can do a pattern. So you can see here that you can do regular expressions or just put in a URL. So as an example, you could do wp-login.php and send them to someplace else. You know what? You don't even need .php. So I've used, I don't know, a membership plugin or something to make my own login page. And you can choose to keep the query string or not. And then this is really cool. You can do conditions. So you can say Only do this if the host is equal to such and such, or the URI is such and such, or query argument. I find this one to be really useful. You can put in, well, example, no cache. You could redirect to someplace based on whether or not there's cache. And then lastly, device code. So you can have this only affect certain devices. So I'm actually going to turn mine off. And let's test this rule real quick. And I didn't actually set up my login, so it's going to send me to a 404. This is very much a demo site, so it should look this broken. All right, that worked. So let's save. All right, so now let's go to wp-login up, and it went to /mylogin, which gives us a nice 404 page because I didn't set up— actually set up one there. But you can see how it works and you can set them up as many as you want. You can edit or delete, and that's how you do redirect rules. So to summarize, on individual websites, you go to Tools, Site Rules, and you can manage header rules or redirect rules. I strongly recommend you use a site like securityheaders.com to see how your site's doing, what you have set, which you don't have set, what the settings are, because you can see right down here what the settings actually are. And you be deliberate about this because it matters. It's important. And then you can also set up redirects, which will be much more performant than a plugin if you only have a few like this. So go forth and secure your website with headers.