Hello again, I’m back after a bit of a break from blogging (only 6 years mind… life got in the way, and insert other excuses here). I thought I’d pay attention to this site again as writing posts is a good way for me to keep up with the latest changes in information security. Here goes…

Web application architecture has changed. The static stacks of the past are largely gone. We now deal with distributed microservices, heavy client-side rendering, and expansive API surfaces. Relying solely on the OWASP Top 10 list is a rookie mistake. It remains a foundational reference, but it is not a complete map of your attack surface.

If you want to find real bugs, you have to look deeper.

The Problem with Conventional Lists

The OWASP Top 10:2025 provides a snapshot of common risks. It is useful for compliance and broad risk assessment. It is not a pentesting methodology. With security misconfigurations appearing in nearly every audited application, static checklists often fail to capture the nuanced interaction between misconfigured components.

You need to focus on how modern apps are actually built.

API-Centric Testing

Modern web apps are essentially API clients. Most business logic resides in backend services, often hidden behind poorly secured endpoints.

Start with reconnaissance. Map the API surface area. Use tools to uncover hidden endpoints, undocumented parameters, and legacy versions of your target services. Once you have a map, focus on these areas:

  • Broken Object Level Authorization (BOLA): Essentially just a shiny new name for IDOR… I tend to report this more generally as though as Broken Access Controls, since if I was writing the code I would see the check it should be making as pretty much the same in either case. This remains the primary killer. Can you access another user’s data by simply changing a resource ID in the request? Never assume the frontend enforces access controls.
  • Excessive Data Exposure: Inspect responses carefully. Does the server send the entire user object when it only needs a display name?
  • Mass Assignment: Can you update fields you shouldn’t control, like is_admin or account_balance, by injecting unexpected properties into an API call?

Authentication and Session Management

Authentication has moved beyond standard login forms. OAuth, OpenID Connect, and JWTs are standard now.

Look for logical flaws in the flow. Can you bypass MFA by manipulating the session state? Are JWTs being validated correctly? Check if tokens can be reused or if signature stripping leads to account takeover. The logic behind the session is where the vulnerabilities hide.

Injection Beyond SQL

SQL injection is still around, but it is often not the most interesting vector. Focus on command injection in microservices or template injection in modern frameworks like React or Vue.

Pay attention to how your input is processed downstream. If a service takes your input and passes it to another internal service, does it sanitise it? Server-Side Request Forgery (SSRF) is often the result of this architectural chain. It is a powerful way to pivot into internal networks that are not exposed to the public internet.

A Practical Approach

Stop checking boxes. Start tracing data flows.

When you sit down to test:

  1. Map the traffic. Understand the handshake between the frontend and the backend.
  2. Identify the boundaries. Where does user input enter the system? Where does it hit a sensitive database or backend command?
  3. Break the logic. Don’t look for standard payloads. Look for what happens when you do something the developers didn’t account for.

Security isn’t about running a scanner and calling it a day. It is about understanding the system well enough to break it in ways the original design didn’t expect.