They say that Laravel isn't secured because PHP is insecure, and that the framework can't be trusted for serious applications. You know, here's what's actually true. Laravel provides strong security defaults out of the box, and most Laravel security vulnerabilities don't actually come from the framework that come from developers disabling those defaults. So let's look at what Laravel actually does to protect you, and we're going to start with

So let's look at what Laravel actually does to protect you, and we're going to start with cross-site request forgery attacks. I'm not going to go into the nitty gritty details of CSRF, but basically it's an attack that tricks authenticated users into performing actions that they didn't intend, like transferring new money or changing passwords. Basically it's done by forging anything that's not a get request. So here I have a form, and it is making a submission to a route with a post

Basically it's done by forging anything that's not a get request. So here I have a form, and it is making a submission to a route with a post request. We can look at this, and here's the two methods. So the create method is for displaying the form. The store method is for handling the form submission. Of course, nothing is going on here. But this would typically be a very bad thing because there's no protection for this submission. It's a post request, even though it's mostly benign, we should protect it with

this submission. It's a post request, even though it's mostly benign, we should protect it with CSRF tokens. So if we take a look in the browser and we click the submit button, we get a 419 page expired. It's interesting. Let's go back. Let's refresh. Let's submit again.

Let's refresh. Let's submit again. And once again, we get a 419 page expired. And there's no circumstance that is going to change that result unless if we include a CSRF token. So by default, in Laravel, if it's not a get request, it is automatically protected with a CSRF token, which means that in our form, we need to include the CSRF directive that

a CSRF token, which means that in our form, we need to include the CSRF directive that is going to inject the CSRF token into the form. So that's whenever we submit the form, it works. So every request, other than get requests, well, probably a head request to anything other than a get or a head is protected with CSRF. And that's very nice. I like it. Next, we need to talk about cross site scripting attacks.

I like it. Next, we need to talk about cross site scripting attacks. These attacks inject malicious JavaScript into our pages. And a lot of times it's done through a query string parameter. So here is the view that I have the view accepts or expects this username. And it's going to output that there. So if we take a look at the controller, here is the method, the XSS method, we can see that we are retrieving the username from the query string and we are just passing that on to

we are retrieving the username from the query string and we are just passing that on to the view. So that sounds like a very bad thing to do. And in most cases, yes, it would be. But let's look at this. We'll go to the XSS, we will have username and I'm going to paste in what would be some JavaScript that would normally be injected into the page. And if we hit enter, we will see that while we see the actual text here, it was

JavaScript that would normally be injected into the page. And if we hit enter, we will see that while we see the actual text here, it was automatically encoded for us. So we didn't have to do anything. We didn't have to do any validation or strip out anything by default. The double curly braces are going to encode whatever is going to be output. So everything is escaped. Everything is essentially made to be treated as just text, or at least that's the end result

Everything is essentially made to be treated as just text, or at least that's the end result whenever we view it in the browser. But of course, there are some times when we want, you know, the raw output, in which case we would need to use very suitably a couple of exclamation points. I love this because this stands out. It's just screaming at you, Hey, be careful with this. So that's now, if we view this in the browser, we can see that the script is actually being

So that's now, if we view this in the browser, we can see that the script is actually being executed. So yes, you know, we could introduce a vulnerability into our views, but by default, anytime we output a value, it is automatically going to be HTML encoded so that it won't execute anything. Next, let's look at hashing, because Laravel has built in hashing using be stripped to hash

Next, let's look at hashing, because Laravel has built in hashing using be stripped to hash passwords, never ever store passwords in plain text. So we are going to accept this value to hash here. So let's use the hash facade, because we have a make method to where we can pass in whatever value that we want to hash, which in this case, is going to be this value. Now we don't have to provide salt or anything like that, because it's automatically done. We can if we want to, but in most cases, we don't need to.

automatically done. We can if we want to, but in most cases, we don't need to. And then of course, if we have a hash value, we want to check the validity of that hashed value. So let's first of all have hashed here so that we can see what that value is. Let's also have the value to hash. Let's make that first. And then we will check to see if the hashed value is actually a hash of our value to hash.

And then we will check to see if the hashed value is actually a hash of our value to hash. We'll call the check method. And I said that wrong. We will see if the value to hash matches hashed value, or did I say that wrong? It's just checking a value to see if it's hashed. And yeah, so inside of the browser, we can go to hash slash and it doesn't matter what we put. I'm going to use my name here, but we can see that the value is Jeremy.

we put. I'm going to use my name here, but we can see that the value is Jeremy. We can see that the hashed value is this wonderful hash, and we can see that the result is true. And this hash is, of course, going to change every time that we refresh, it's going to change the hash because that's what hashing does. But the fact that it is built in and available to use whenever you need to hash a password and store it within a debate database, or whenever you need to check to see if

a password and store it within a debate database, or whenever you need to check to see if a value matches its hashed value, then everything is right there and available with the hash facade. Next, we have rate limiting, which we don't always need, but it has its uses. So here I have several routes set up. Let me organize that just a little bit better. So everything that we are working with in this episode has a prefix of security

Let me organize that just a little bit better. So everything that we are working with in this episode has a prefix of security . It's all on the security controller. And then I have these group of routes for that. But let's say that I want to add some rate limiting here. Well, we can do that using some middleware. It's called the throttle middleware, and we can say that we want to allow five requests within a minute for a given IP.

requests within a minute for a given IP. And that's going to be perfectly fine. All we have to do is use the throttle middleware for whatever routes that we want to throttle. And there it is. We're done. So of course you can customize this per route per user or based on really any attribute because it's middleware.

attribute because it's middleware. Next thing is mass assignments. Now this has usually been where, you know, vulnerabilities start to creep into our application because mass assignment can be a very dangerous thing. Let's look at the user model. So by default, a model is not fillable. Basically meaning that if we wanted to create a new user, we would want to explicitly define

Basically meaning that if we wanted to create a new user, we would want to explicitly define the attributes that we allow to be, you know, mass assigned, in which case we would use this fillable protected property inside of our model. And the user post every model by default has a fillable array, but it's usually empty, therefore making it impossible to mass assign the attributes for a model. So you would want to define the attributes you want to allow and voila, you have protected

So you would want to define the attributes you want to allow and voila, you have protected yourself from mass assignment. It's built in its default. So you have to explicitly go around it to introduce vulnerabilities via mass assignment. Next, let's talk about SQL injection because that's a biggie. Now let me first of all say this. If you use the query builder or you use eloquent, you basically don't have to worry about SQL

If you use the query builder or you use eloquent, you basically don't have to worry about SQL injection because everything is parameterized for you. However, if you are just executing a raw SQL query like this, you could introduce a SQL injection vulnerability just like I've done here. Never do this because all you have to do is use parameters. So with the DB facade, all you have to do is specify your query, use parameters for any values that you need to include with that query.

for any values that you need to include with that query. And then as a second argument, use your bindings. It's just an array of whatever values that you want to include. So in this case, there's only one value because if the email is equal to what was provided by search, then great. But if we had multiple parameters, then we could have parameter one and parameter two and so on and so forth.

parameter two and so on and so forth. So again, if you use the query builder or if you use eloquent, you're pretty much fine. But if you use the DB facade to execute raw SQL queries, think in terms of parameters because parameters pretty much single handedly thwart any SQL injection attack. So is Laravel secure? Well, the framework provides strong defaults that protect you by default. So most vulnerabilities come from developers doing something stupid and turning

Well, the framework provides strong defaults that protect you by default. So most vulnerabilities come from developers doing something stupid and turning them off. Don't do that because Laravel is as secure as you let it be. The protections are there. So use them.