IDOR is when you can access or modify data just by tweaking the URL or API request, and the system doesn’t check whether you should be allowed to. Let’s say you’re logged in as a test user, and you spot a URL that end in : orders/view/123That number at the end might be your order ID. But what happens if you change it to: orders/view/124 ...and suddenly you're viewing someone else’s order? Maybe you can even delete or modify it. That’s an IDOR, a lack of proper access control. It’s not just websites either. You can try the same thing in APIs using tools like Postman. Change the ID in the request and see if you can grab or update someone else’s data. If you can, it means there’s no access check, and that’s a critical security flaw.

Cross-site scripting, also known as XSS, is one of the most prevalent issues you get in web applications. It’s an issue we all need to be very wary of, as it's fairly easily discovered by attackers, but it’s also quite easy to test for. It’s a type of vulnerability that doesn’t go after the website itself, but instead goes after the user of the application. It works by injecting JavaScript into an input, and that script then runs for whoever is using the page. When testing, one common technique is to try and make an alert box pop; just a teeny tiny bit of JavaScript, usually something like <script>alert(1)</script>. If you can get that to run, that means your script has executed, and you've found a cross-site scripting issue. That might seem harmless, but it shows the door is open. A more skilled attacker could go on to do much worse things, like stealing cookies, hijacking sessions, redirecting users to fake websites, or stealing passwords. So even just getting the alert to show is a big red flag. Types of Cross-Site Scripting: Reflected XSS: If you can get the attack into a URL and send it to someone, like over Slack or social media, and it runs when they open it, that’s a reflected attack.  Persistent XSS: If the script gets saved to the database and runs for anyone who visits the page, that’s a persistent attack. And that’s a really bad one, a critical issue that needs fixing immediately. Top tips for testers getting started: Start simple by trying to make an alert box pop up; it’s a safe and easy way to show that JavaScript can run. Try placing your JavaScript test input in different places, like form fields or in the URLs. Try saving your test input and check if it runs when other users load the page. If it does, the application might have a persistent XSS vulnerability. Test reflected XSS by copying the full URL and sharing it with a friend (make sure they know you’re testing). If you want to explore further, try using JavaScript to redirect the user or show a fake login screen, this helps you understand how serious the impact can be.

A group of people having a lean coffee session at TestBash 2024.

In this episode of QA Therapy, we sit down with Richard Adams, a seasoned expert in security testing, to dive deep into the critical role security plays in modern software development.

Photo of an arm with both the ministry of testing ninja and the newer mot logo amongst other tattoos.

The more 99 Second Talks, the better!

First day of 99 Second Talks at TestBash Brighton 2024

Richard Adams and Ben Dowen ad the pre-bash social

Boost your career in software testing with the MoT Software Testing Essentials Certificate. Learn essential skills, from basic testing techniques to advanced risk analysis, crafted by industry experts.