API security testing for a startup with no security team

A startup without a security team can test its API well by working through the OWASP API Security Top 10 in order of likelihood: authorization first, then authentication, then resource limits and inventory. Automate scans in CI, add authorization tests to your normal test suite, and accept that no scanner will find your business logic flaws.

Where should we start?

Start with the list that was written for this job. The OWASP API Security Top 10 (2023) names ten risks, and the first five are about who is allowed to do what: broken object level authorization, broken authentication, broken object property level authorization, unrestricted resource consumption and broken function level authorization. The rest cover sensitive business flows, server side request forgery, security misconfiguration, improper inventory management and unsafe consumption of APIs.

You will not fix all ten this quarter. Pick the order below and you will cover the likeliest failures first.

Step 1: write the inventory down

Improper inventory management is on the list because teams cannot test what they have forgotten. List every endpoint, version and environment, including old versions still running and staging systems reachable from the internet. Your API gateway, your router definitions or an OpenAPI file can generate this. Everything else depends on it.

Step 2: test authorization with real users

Object level authorization is the first item for a reason. The test needs no special tool: create two ordinary users, record the identifiers of user A's objects, then request them as user B. The server should refuse. Repeat for each endpoint that takes an identifier, and then for each action (read, update, delete). Write these as automated tests in your existing framework so they run on every change.

Do the same across roles. If an admin endpoint exists, call it as a normal user. This covers function level authorization.

Step 3: check authentication and limits

Review how tokens are issued, how long they live and whether they can be revoked. Test that missing, expired and tampered tokens are rejected. Then check resource consumption: do list endpoints cap page size, do uploads cap file size, and does something throttle repeated requests from one caller?

Step 4: add automated scanning

Dynamic scanning sends requests to a running API and flags misconfiguration, missing headers and some injection issues. Software composition scanning flags vulnerable libraries, and reachability analysis helps you see which ones your code can actually call. Run both in CI so results appear in the pull request. Safeguard includes dynamic application testing and dependency analysis, and the demo below shows a web app scan.

Open the DAST web app scan demo

What will a tool miss?

Scanners do not understand your business. Unrestricted access to sensitive business flows, such as someone abusing a coupon or reservation feature, needs a person who understands the flow. The same goes for subtle authorization bugs in unusual endpoints. Plan one focused review each quarter where an engineer other than the author reads the riskiest endpoints with the Top 10 beside them. For a high-stakes launch, an outside penetration test is reasonable.

What to do

1. Generate an inventory of endpoints, versions and environments, and retire what you do not need.
2. Write automated tests with two users and two roles for every endpoint that takes an identifier.
3. Review token lifetime, revocation and rejection of bad tokens.
4. Set page size, upload size and rate limits, and test them.
5. Run dynamic and dependency scans in CI and fail builds on agreed severity.
6. Hold a quarterly peer review of the riskiest endpoints against the OWASP list.
7. Schedule an outside test before major launches or enterprise deals that require one.

Quick check

Sources

• OWASP API Security Top 10 2023

Last reviewed: 18 October 2026.