In Depth: Signed URLs
[InDepth#9] One of the many awesome and completely underrated Laravel security features.
Greetings friends! I write to you today, a few days short of the 9 month anniversary1 of Laravel Security in Depth (it’s Tuesday), and my dashboard says 906 subscribers - which is just incredible. 🥰 Thank you so much for joining me on this journey! It looks like I’ve got 3 months to start planning something big for the 12 month anniversary!
I hope you learnt a lot from last week’s In Depth on Policy Objects, and we’re following the theme this month by diving into another of Laravel’s awesome (but totally underrated) features: the humble Signed URLs. I love Signed URLs because they can be used in so many situations, and they avoid the need for messing around with custom hashes, forcing authentication, and messy expiry dates. You just call one function, add some middleware, and that’s literally it. It’s so simple.
In a nutshell, Signed URLs are a way to securely verify that the requested URL has not been modified. They don’t directly offer authentication or authorisation, anyone who gains access to a signed URL can use it, but they do prevent modification to the URL. This means they’ll prevent someone changing an ID or Slug, trying to guess other resources and access other pages. It’s this power that allows them to be used in a wide variety of cases where you’d normally need to consider some method of obfuscation or randomness.
That said, from a technical point of view, all it does is generate a 64-character SHA256 hash (we’ll look at this in more detail below) and add that to the URL. So you could easily implement that yourself using cache values or database lookup columns, but the benefit of a signed route is you don’t need to do any of that. It just works out-of-the-box.
To get a feel for how they work, let’s look at three different use cases:
Email Unsubscribe Links
Blog Post Preview Links
Multi-page Content Magic Links