💥🐹 4 new Go Code Review Labs just dropped! 🐹💥 Read the code, peek at the diff, find the bug. Sharpen your skills: pentesterlab.com/badges/gola…

Assumptions are at the root of so many security issues. When testing an application or reviewing code, always ask yourself: "What assumptions did the developer make? What assumptions am I making when I say this is secure?" Maybe you're assuming that an input has already been validated, that a route requires authentication, or that a framework handles a security check for you. Each of those assumptions deserves to be verified. Questioning the developer's assumptions is part of the job, but questioning your own is just as important.

With moderation...

Getting a CVE is easy when you're the one writing the vulnerabilities. Just make sure you clarify what you mean by "responsible for 30 CVEs" on your resume... 😉

Put some Spark in your relationship. 💍

What do you wish someone had taught you before your first client pentest? We've just released Pentest Process: 9 exercises covering scoping, client communication, reporting and retesting. If you're mentoring a junior pentester, send them this: pentesterlab.com/badges/pent…

This is an image we keep using in our training, because you don't want to be the man at the bottom. In our experience, most people stop at roughly the same point: when it gets hard, they've run out of ideas, and they feel like they’ve tried everything. When you reach that point, go for a walk, take a break, or take a shower. Give yourself some time away from the problem, then come back and push a little further. Revisit an assumption, investigate the behaviour you couldn't quite explain, or try the idea you dismissed earlier. Coming back with a fresh perspective can help you see something you missed after hours of staring at the same code or requests. We've seen it again and again: some of the best bugs are discovered when you push a little further after you thought you were completely done.

Security vendors' threat models be like:

Do you want to be able to write your own Java gadgets like the ones in ysoserial? Make sure you check out our Java Deserialisation badge: pentesterlab.com/badges/java… We just dropped two new labs!

Why is AI code review so easy to adopt? What makes pentesting agents harder to deploy? Which skills should you keep developing? Watch the recording of our webinar: "The Uneven Impact of AI on Offensive Security" with @PentesterLab's founder @snyff: youtube.com/watch?v=IqghiUqx…

Learning to hack...

If you don’t really know how something should be implemented, or which security checks should be in place, play spot the difference. Pick another codebase in the same language doing something similar, ideally a more mature or hardened one, and compare how they handle the same thing. Sometimes finding the difference is enough to point you in the right direction.

One of the biggest mistakes beginners make when testing an application is not reading the error messages properly. They send a payload, get an error and conclude that it did not work. Then they send another payload, get another error and assume it is basically the same thing. But an error does not mean the payload did not work. It just means that an error was triggered somewhere in the execution path, and that point may be after the interesting part already happened. Your payload may have been parsed successfully, changed the control flow, bypassed a check, reached a different function or triggered behaviour that the previous payload did not. Something later may simply have failed. This is why small differences matter so much. A different exception, a slightly different message, a different status code or even a different location in a stack trace can tell you that you moved forward. Security testing is often about noticing those tiny changes and asking why they happened. Don’t just look for success or failure. Read the error.