Following on from last week’s Validating User Input security tip, we’re looking at Escaping Output Safely this week. This is our third In Depth email, and like my last In Depth about SQL Injection, I’ve set up a demo site with some challenges for you to explore XSS further. So check that out and have some fun! 😁

As always, let me know if you’ve got any questions or suggestions for topics. Enjoy!

Escaping Output Safely

I said this a few times in the last email, but it’s worth repeating here:

Don’t trust user input. Don’t trust user input. Don’t trust user input.

But why?

Users can be crafty and sneaky1, and if they have malicious intent, they can come up with all sorts of creative and unusual ways to subvert the behaviour of your applications intentionally. Our job as developers is to build a system that prevents these sneaky users from doing things that we don’t want them to do, while still allowing them to do everything we do want them to do.

What is Cross-Site Scripting?

A common trick that sneaky users (i.e. hackers) love to do is inject their own javascript into websites, and then trick other users into executing that javascript. Because, as an attacker, if you can get your javascript running in a victim’s browser, it gives you full control of their browser. This is known as Cross-Site Scripting, or XSS, and it is usually the result of not escaping user output safely.

Cross-Site Scripting (XSS) comes in two flavours: Stored and Reflected. They both have the same result - the attacker injects javascript into the page through unescaped output - but they differ in how the javascript gets onto the page and where it is stored.

Let’s take a look at both:

Laravel Security In Depth

Laravel Security In Depth: Escaping Output…

Comments on this post are for paid subscribers