After a great day of learning, chatting and exploring possibilities, it is always nice to look back at everything from the day... Plus the swag! Bring on Day 2!

Learn how to build security into your day-to-day testing!

I’m coming from: Edinburgh, UK My role is: former Quality Coach and now free range tester (i.e. unemployed >_<) I’d love to meet others who are into: Exploratory testing & quality coach...

The term "quality" is essential in software yet we all have different understandings of it

Strengthen your security testing by learning how simple tools can uncover vulnerabilities before attackers do.

Eighteen months, 19 modules, and 59 amazing contributors later, the MoT Software Testing Essentials Certification is complete! Looking back, my favourite part has been seeing so many community m...

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.