REST API Security Calculator
Score a REST API against the ten OWASP API Security risks and see which category is dragging the result down.
Inputs
OWASP API Top 10 Score
52/ 100
Maturity Grade
D — Weak
Weakest Category
API3 Broken object property level authorisation
Categories Below 'Mostly Enforced'
4
Unaddressed Categories
0
Residual Exposure
48%
Step by step
Values used
API1 — object-level authorisation on every read and write = Mostly enforced — 6; API2 — authentication on every endpoint = Enforced and covered by tests — 10; API3 — property-level authorisation, no mass assignment = Partial or ad hoc — 3; API4 — resource consumption limits = Mostly enforced — 6; API5 — function-level authorisation by role = Mostly enforced — 6; API6 — protection of sensitive business flows = Partial or ad hoc — 3; API7 — SSRF controls on outbound fetches = Mostly enforced — 6; API8 — hardened configuration and headers = Mostly enforced — 6; API9 — inventory and version management = Partial or ad hoc — 3; API10 — validation of third-party API responses = Partial or ad hoc — 3
REST API Security
Each of the ten OWASP API Security risks scores 10 when enforced and tested, 6 when mostly enforced, 3 when partial and 0 when unaddressed, so the ten categories sum to a 0–100 posture score.
OWASP API Top 10 Score
= 52 / 100
Maturity Grade
= D — Weak
Weakest Category
= API3 Broken object property level authorisation
Categories Below 'Mostly Enforced'
= 4
Unaddressed Categories
= 0
Residual Exposure
= 48
How it works
The ten categories are weighted equally because the OWASP list is ordered by observed frequency rather than by severity, and in practice any single unaddressed category is enough for a breach. The weakest-category output exists because the average hides the one that matters. API risks are not the web risks — authorisation and inventory dominate, and neither is found by a scanner that only knows how to look for injection.
Formula
REST API Security
Each of the ten OWASP API Security risks scores 10 when enforced and tested, 6 when mostly enforced, 3 when partial and 0 when unaddressed, so the ten categories sum to a 0–100 posture score.
- API1
- Object-level authorisation — the most exploited API risk
- API9
- Inventory — shadow and retired API versions
Frequently Asked Questions
How is REST API Security calculated?
Each of the ten OWASP API Security risks scores 10 when enforced and tested, 6 when mostly enforced, 3 when partial and 0 when unaddressed, so the ten categories sum to a 0–100 posture score. The ten categories are weighted equally because the OWASP list is ordered by observed frequency rather than by severity, and in practice any single unaddressed category is enough for a breach. The weakest-category output exists because the average hides the one that matters.
Why does REST API Security matter?
API risks are not the web risks — authorisation and inventory dominate, and neither is found by a scanner that only knows how to look for injection.
What values do I need to enter?
This calculator takes 10 inputs: API1 — object-level authorisation on every read and write, API2 — authentication on every endpoint, API3 — property-level authorisation, no mass assignment, API4 — resource consumption limits, API5 — function-level authorisation by role, API6 — protection of sensitive business flows, API7 — SSRF controls on outbound fetches, API8 — hardened configuration and headers, API9 — inventory and version management, API10 — validation of third-party API responses. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Why is object-level authorisation the hardest to fix?
Because it has to be checked in every handler, against the specific object being touched, and no framework can infer your ownership rules. The reliable pattern is a single authorisation helper called with the subject, the action and the loaded object, plus a test per endpoint that proves another tenant's identifier returns 404.