Skip to content
Calcrivo

API Security Score Calculator

Score your API estate across authorisation, authentication, rate limiting, schema validation, transport and monitoring, minus shadow APIs.

Inputs

%
%
%
%
%
%
%
APIs
APIs

API Security Score

67/ 100

API Security Grade

C — Fair

Weighted Pillar Score

70.5/ 100

Shadow API Share

12.2%

Shadow API Deduction

3.7points

Highest-Value Fix

Log and alert on anomalous access breadth per credential

Step by step

  1. Values used

    Object-level authorisation coverage = 65 %; Authentication strength = 80 %; Rate limiting coverage = 70 %; Request and response schema validation coverage = 60 %; Transport security = 90 %; Logging and anomaly monitoring coverage = 55 %; Documented inventory coverage = 75 %; APIs in the estate = 180 APIs; Shadow, deprecated or undocumented APIs = 22 APIs

  2. API Security Score

    pillar score = 0.20 object-level authorisation + 0.18 authentication + 0.14 rate limiting + 0.14 schema validation + 0.12 transport + 0.12 monitoring + 0.10 inventory, each 0–100.

  3. Shadow API deduction

    final score = pillar score − 0.3 × shadow API share, where the shadow share is undocumented or deprecated APIs as a percentage of the estate.

  4. API Security Score

    = 67 / 100

  5. API Security Grade

    = C — Fair

  6. Weighted Pillar Score

    = 70.5 / 100

  7. Shadow API Share

    = 12.2

  8. Shadow API Deduction

    = 3.7 points

  9. Highest-Value Fix

    = Log and alert on anomalous access breadth per credential

How it works

Object-level authorisation carries the heaviest weight because it is the most frequently exploited API weakness and the one no gateway can enforce for you. The shadow deduction reflects that coverage percentages are measured against the APIs you know about, so an undocumented estate inflates every other number. API estates grow faster than the controls around them, and the endpoints that cause incidents are usually the ones nobody remembered were still deployed.

Formulas

API Security Score

pillar score = 0.20 object-level authorisation + 0.18 authentication + 0.14 rate limiting + 0.14 schema validation + 0.12 transport + 0.12 monitoring + 0.10 inventory, each 0–100.

object-level authorisation
The most exploited API weakness, so the heaviest weight
inventory
Share of the estate that is documented and owned

Shadow API deduction

final score = pillar score − 0.3 × shadow API share, where the shadow share is undocumented or deprecated APIs as a percentage of the estate.

shadow API
An endpoint in production that no inventory or policy covers
0.3
Points removed per percentage point of shadow estate

Frequently Asked Questions

How is API Security Score calculated?

pillar score = 0.20 object-level authorisation + 0.18 authentication + 0.14 rate limiting + 0.14 schema validation + 0.12 transport + 0.12 monitoring + 0.10 inventory, each 0–100. Object-level authorisation carries the heaviest weight because it is the most frequently exploited API weakness and the one no gateway can enforce for you. The shadow deduction reflects that coverage percentages are measured against the APIs you know about, so an undocumented estate inflates every other number.

Why does API Security Score matter?

API estates grow faster than the controls around them, and the endpoints that cause incidents are usually the ones nobody remembered were still deployed.

What values do I need to enter?

This calculator takes 9 inputs: Object-level authorisation coverage, Authentication strength, Rate limiting coverage, Request and response schema validation coverage, Transport security, Logging and anomaly monitoring coverage, Documented inventory coverage, APIs in the estate, Shadow, deprecated or undocumented APIs. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

How do I find shadow APIs?

Work from traffic rather than documentation: pull hostnames and paths from gateway and load-balancer logs, cloud provider inventories and DNS records, then subtract what your specification catalogue covers. Whatever is left is unowned by definition, and each one needs an owner, a retirement date or a policy.

You might also need