CSRF Protection
Introduction
Cross-site request forgeries are a type of malicious exploit whereby unauthorized commands are performed on behalf of an authenticated user. Thankfully, Hypervel makes it easy to protect your application from cross-site request forgery (CSRF) attacks.
An Explanation of the Vulnerability
In case you're not familiar with cross-site request forgeries, let's discuss an example of how this vulnerability can be exploited. Imagine your application has a /user/email
route that accepts a POST
request to change the authenticated user's email address. Most likely, this route expects an email
input field to contain the email address the user would like to begin using.
Without CSRF protection, a malicious website could create an HTML form that points to your application's /user/email
route and submits the malicious user's own email address:
<form action="https://your-application.com/user/email" method="POST">
<input type="email" value="[email protected]">
</form>
<script>
document.forms[0].submit();
</script>
Preventing CSRF Requests
Hypervel automatically generates a CSRF "token" for each active user session managed by the application. This token is used to verify that the authenticated user is the person actually making the requests to the application. Since this token is stored in the user's session and changes each time the session is regenerated, a malicious application is unable to access it.
The current session's CSRF token can be accessed via the request's session or via the csrf_token
helper function:
use Hypervel\Http\Request;
Route::get('/token', function (Request $request) {
$token = $request->session()->token();
$token = csrf_token();
// ...
});
Anytime you define a "POST", "PUT", "PATCH", or "DELETE" HTML form in your application, you should include a hidden CSRF _token
field in the form so that the CSRF protection middleware can validate the request. For convenience, you may use the @csrf
Blade directive to generate the hidden token input field:
<form method="POST" action="/profile">
@csrf
<!-- Equivalent to... -->
<input type="hidden" name="_token" value="{{ csrf_token() }}" />
</form>
The App\Http\Middleware\VerifyCsrfToken
middleware, which is included in the web
middleware group by default, will automatically verify that the token in the request input matches the token stored in the session. When these two tokens match, we know that the authenticated user is the one initiating the request.
Excluding URIs From CSRF Protection
Sometimes you may wish to exclude a set of URIs from CSRF protection. You should place these kinds of routes outside of the web
middleware group that the App\Providers\RouteServiceProvider
applies to all routes in the routes/web.php
file. However, you may also exclude the routes by adding their URIs to the $except
property of the VerifyCsrfToken
middleware:
<?php
namespace App\Http\Middleware;
use Hypervel\Foundation\Http\Middleware\VerifyCsrfToken as Middleware;
class VerifyCsrfToken extends Middleware
{
/**
* The URIs that should be excluded from CSRF verification.
*/
protected array $except = [
'http://example.com/foo/bar',
'http://example.com/foo/*',
];
}
Note
For convenience, the CSRF middleware is automatically disabled for all routes when running tests.
X-CSRF-TOKEN
In addition to checking for the CSRF token as a POST parameter, the App\Http\Middleware\VerifyCsrfToken
middleware will also check for the X-CSRF-TOKEN
request header. You could, for example, store the token in an HTML meta
tag:
<meta name="csrf-token" content="{{ csrf_token() }}">
Then, you can instruct a library like jQuery to automatically add the token to all request headers. This provides simple, convenient CSRF protection for your AJAX based applications using legacy JavaScript technology:
$.ajaxSetup({
headers: {
'X-CSRF-TOKEN': $('meta[name="csrf-token"]').attr('content')
}
});
X-XSRF-TOKEN
Hypervel stores the current CSRF token in an XSRF-TOKEN
cookie that is included with each response generated by the framework. You can use the cookie value to set the X-XSRF-TOKEN
request header.
This cookie is primarily sent as a developer convenience since some JavaScript frameworks and libraries, like Angular and Axios, automatically place its value in the X-XSRF-TOKEN
header on same-origin requests.