OWASP Beyond the Top 10: API Security, LLM Top 10, ASVS and the Cheat Sheet Series

Version note: This post covers the other OWASP projects alongside the OWASP Top 10:2025 (API Security Top 10 2023, Top 10 for LLM Applications 2025, ASVS 5.0); the code was tested with ASP.NET Core 10 (.NET 10).

Guess First

The Bookstore API has an endpoint that returns the reviews of a book. The handler returns the Review objects from the database as they are, and every Review contains a User object representing its author. The endpoint is anonymous and needs no sign-in. Apart from the review text and the author's name, what do you see in the JSON?

In my own lab, the first attempt's response also contained the email, passwordHash and isAdmin fields. Nobody bypassed an authorization check; the endpoint did exactly what it was written to do. In the Top 10 this problem belongs under A01 (exposure of sensitive information, CWE-200 and CWE-201, is mapped there), but in the OWASP API Security Top 10 it has its own name. In the last post of the series we step outside the Top 10 and look at OWASP's other lists. The examples again run only on your own machine; only try these techniques on systems you own or have written permission to test.

Why One List Is Not Enough

The Top 10 is an awareness document that covers web applications in general. Because it is general, it stays coarse in some areas. The most common mistake in a REST API and the most common mistake in an application wired to a language model are not the same. That is why OWASP runs separate lists and separate projects for specific areas. It helps to sort them into three groups: awareness lists (API Security Top 10, Top 10 for LLM Applications), a verification standard (ASVS) and "how to" guides (Cheat Sheet Series).

API Security Top 10 (2023)

The current edition is 2023. The items are: API1 Broken Object Level Authorization (BOLA), API2 Broken Authentication, API3 Broken Object Property Level Authorization (BOPLA), API4 Unrestricted Resource Consumption, API5 Broken Function Level Authorization (BFLA), API6 Unrestricted Access to Sensitive Business Flows, API7 Server Side Request Forgery, API8 Security Misconfiguration, API9 Improper Inventory Management and API10 Unsafe Consumption of APIs.

The list speaks in finer detail than the Top 10. The Top 10's Broken Access Control is split into three levels here: object level (BOLA, the API name for IDOR), property level (BOPLA) and function level (BFLA). In post 3, reading another user's order was BOLA, and the missing check on the admin endpoint was BFLA. The review endpoint from the opening is BOPLA: access to the object is correct, but which of the object's properties are visible was never checked. The same item also covers the "the client can write a property it should not" case from the mass assignment post.

API9 Improper Inventory Management has no direct counterpart in the Top 10: not knowing which API versions are exposed, in which environments, with which endpoints. A forgotten v1 or a test environment left open to everyone is a door, however solid the rest of the code is.

An Example: API3 and a Response DTO

The fix is to separate the data model from the API contract. The endpoint returns not the entity but a response DTO that carries only the fields you want to show:

WebApplicationBuilder builder = WebApplication.CreateBuilder(args);
WebApplication app = builder.Build();

User ada = new(1, "Ada", "ada@example.com", "dev-only-not-a-real-hash", IsAdmin: false);
List<Review> reviews = [new(1, BookId: 1, "Great book", ada)];

app.MapGet("/books/{id:int}/reviews", (int id) =>
    reviews.Where(r => r.BookId == id)
           .Select(r => new ReviewResponse(r.Id, r.Body, r.Author.DisplayName)));

app.Run();

public record User(int Id, string DisplayName, string Email, string PasswordHash, bool IsAdmin);
public record Review(int Id, int BookId, string Body, User Author);
public record ReviewResponse(int Id, string Body, string AuthorName);

$ curl -i http://localhost:5191/books/1/reviews
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Date: Fri, 06 Nov 2026 19:08:08 GMT
Server: Kestrel
Transfer-Encoding: chunked

[{"id":1,"body":"Great book","authorName":"Ada"}]

Now the response has only three fields. The nice part of this approach is that it flips the default: when a new property is added to the entity tomorrow (PhoneNumber, LastLoginIp), it does not leak into the API on its own; someone has to add it to ReviewResponse on purpose. If you use EF Core, projecting with Select also brings a performance gain, since unneeded columns are never fetched from the database. On the write side the same principle applies as an input DTO; the UnmappedMemberHandling.Disallow setting from post 17 is its seat belt in JSON.

Top 10 for LLM Applications (2025)

This list, run under OWASP's GenAI Security Project, focuses on applications that use language models. The items of the 2025 edition: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Supply Chain, LLM04 Data and Model Poisoning, LLM05 Improper Output Handling, LLM06 Excessive Agency, LLM07 System Prompt Leakage, LLM08 Vector and Embedding Weaknesses, LLM09 Misinformation and LLM10 Unbounded Consumption.

The list contains familiar ideas. Prompt injection is injection in a new interpreter: data is treated as an instruction to the model. Improper Output Handling is failing to treat the text the model produces as untrusted input; writing the model's answer into innerHTML is the same XSS as in post 10. Excessive Agency is the principle of least privilege applied to the model: if you give the model a tool, limit what that tool can do. The practical takeaway for a .NET developer: everything going into and coming out of the model is subject to all the rules we have discussed so far.

ASVS 5.0 and the Cheat Sheet Series

As we touched on in post 17, ASVS is the standard that turns the Top 10's "what to watch out for" into "what to verify". The current stable version is 5.0.0, published on May 30, 2025. The requirements are split into three levels; a low-risk application starts at the first level, while an application handling sensitive data aims for the higher ones. If you can tie a requirement to a test, a CI rule or the code review list, you are really applying it.

The Cheat Sheet Series (cheatsheetseries.owasp.org) is a set of short, practical guides per topic. The password storage iteration counts and the warning about tokens in localStorage in this series come from there. When you have a "how is this done in practice" question, this is the first place to look; but read every guide together with your framework's documentation (learn.microsoft.com, angular.dev), because the guides are written language-agnostic.

Where the Series Goes Next

This series covered the OWASP Top 10:2025 through ASP.NET Core 10 and Angular and showed how the list has changed from 2017 to today. When a new Top 10 edition comes out, the series will continue with it: a new comparison post for the changed categories, and updated code in the category posts.

The next security series will go deeper into three areas we only touched here. The authentication series covers passkeys, OpenID Connect and the token lifecycle; the ASP.NET Core security series covers authorization handlers, Data Protection and secure configuration; the frontend security series covers CSP, Trusted Types and the BFF pattern for SPAs.

Common Pitfalls

The first is evaluating your API with the Top 10 alone. Property-level authorization and API inventory are not separate items in the Top 10; unless you also look at the API Security Top 10, both are easy to miss.

The second is filtering the response on the client. Not showing the email field in an Angular template does not remove it from the response; anyone can see it in the browser's developer tools. Filtering happens on the server, with a DTO.

The third is keeping an LLM-backed feature out of security review because "AI is a separate world". The model's output must be encoded like user input, and the tools the model calls must be authorized.

The fourth is trying to apply all of ASVS at once. Pick a level, start with the requirements that fit your application, and tie a few to tests with every release.

Checklist

Go through the API Security Top 10 item by item for your API: does every endpoint have authorization at the object, property and function level? Entities are not returned from the API; every endpoint has its own response and input DTO. There is an inventory of every exposed API version and environment. Resource consumption is controlled with rate limiting and size limits. In features that use an LLM, model output is encoded and the tools given to the model are defined with least privilege. An ASVS level has been chosen for the application and some of its requirements are tied to tests. When deciding on a topic, the relevant cheat sheet and the framework documentation are read together.

A Small Experiment

★☆☆ Add a CreatedAt field to the review endpoint. First add it only to the Review record and see that the response does not change; then add it to ReviewResponse and confirm it appears in the response.

★★☆ List all endpoints in your lab (you can reuse the EndpointDataSource test from post 17) and mark each one against the first five items of the API Security Top 10. Which endpoint is missing a property-level check?

★★★ Write an integration test that guarantees nothing other than ReviewResponse is returned: read the property names from the response JSON and compare them exactly with the expected list. See that the test still passes when you add a new field to the entity, and breaks when you add one to the DTO.

The series ends here, but the topic does not. In the next security series we start with authentication: we go beyond passwords and look at passkeys, OpenID Connect and the lifecycle of a token from the moment it is issued to the moment it is revoked.