What we still need to verify : 3 points in this profile are not yet confirmed against vendor documentation.
- Scope and limits of the free tier: confirm with vendor
- Current CI/CD and ticketing integration list: verify against vendor docs
- Whether traffic based discovery is offered alongside spec driven testing: confirm
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
APIsec generates its test suite from an API definition rather than from a fixed list of payloads. You supply an OpenAPI or similar specification plus credentials for multiple user roles, and the platform builds a model of the API: endpoints, parameters, object identifiers and the relationships between them. From that model it synthesizes test cases, runs them against a live instance, and reports which produced a response that should not have been possible.
The emphasis is on flaw classes generic scanners miss because they require understanding of who is allowed to do what. Broken object level authorization is the central one: the platform captures an object identifier while authenticated as one user, then requests the same object as a different user or with no credentials at all, and treats a successful response as a finding. The same approach covers broken function level authorization, mass assignment, parameter tampering, and workflow sequencing where a step is skipped or replayed. Injection and misconfiguration checks run alongside.
Where it fits
This is a pre release gate. It runs against a deployed test or staging environment, triggered on a schedule or from the pipeline after a deployment step, and returns a pass or fail a build can act on. Ownership tends to sit with an application security team that configures specifications and role credentials once, with results routed to the teams that own each API. Two things have to already be true: the specification has to describe the API accurately, and you need working credentials for at least two roles with genuinely different permission levels. Without the second, the authorization testing that justifies the tool does not run.
Strengths
- Multi role replay turns broken object level authorization, tedious to find manually, into an automated check.
- Test generation from the specification means new endpoints get coverage as soon as they appear, without anyone writing tests.
- Pipeline integration returns a gate decision rather than a report to triage later.
- Findings include the request sequence that produced them, which makes reproduction straightforward.
Limitations
- Spec driven, so undocumented and shadow endpoints go untested. It does not build an inventory from live traffic.
- You need a stable staging deployment with representative seeded data. Thin test data produces thin results.
- Generated authorization tests can write or delete data. Running them anywhere near production requires care.
- Role and credential configuration drifts as the application changes and needs ongoing maintenance.
Who it suits
Teams with maintained API specifications and a real staging environment who want authorization coverage without hiring a pentester per release. Organizations whose main problem is not knowing what APIs they have should start with a discovery tool.
Used APIsec? Recommend it under your own name and title.
Recommend this tool