APIs.io spends all day looking at other people’s APIs — indexing them, and rating how well they describe themselves with a Spectral-powered scoring system. It is a fair question to ask right back at us: how does the API behind the index hold up? So we pointed a security ruleset at our own apis.io API and published the results, the same way we would want any publisher in the catalog to.
What we ran, and what it found
We used the Spectral OWASP ruleset from API Commons — a grounded, owned mapping of the OWASP API Security Top 10 (2023) that runs on plain Spectral, no platform required. The first pass over the apis.io OpenAPI came back with 216 findings, and none of them were blocking errors. The shape was honest and unsurprising for a spec that was written to describe a search API, not to defend one: the large majority were API4 Unrestricted Resource Consumption — string, array, and integer schemas with no upper bound declared — followed by operations that never stated a security requirement at all, plus a URL-bearing field that should carry format: uri.
Then we remediated and ran it again, and the second pass came back clean — 216 to 0. We added maxLength, maxItems, and maximum bounds so no field is unbounded, and we made a deliberate call on authentication: apis.io is a public, read-only discovery API, so the honest fix is to declare security: [] — explicitly public — rather than fake an auth requirement the API does not have, while leaving an API key scheme defined so we can add metering later without breaking anyone. And we will keep repeating the caveat that comes with the ruleset itself: a clean report is a floor, not a certificate. Static linting cannot see runtime authorization or abuse — it can only make sure the design-time contract is not leaving an obvious door open.
The reports live next to the API
The part that matters most is not the zero — it is that both runs are committed in GitHub right next to the API definition, under a timestamped folder in the apis.io repository: the baseline, the remediated run, each with the standalone HTML report, the raw Spectral findings, a SARIF file for code scanning, and a short README of counts and provenance. The before and after sitting side by side in git history are the diff — a durable record of what we checked, what we fixed, and when. That is the same discipline apis.io applies outward to the whole network — describe the thing as structured data, then make the record findable — turned back on ourselves.
Why the index holds itself to this
An index that rates other APIs on how well they document themselves should be able to show its own homework. This is the companion to the work API Evangelist just published across its own APIs, and it is the pattern we would love to see more publishers adopt: run the security rules against your own OpenAPI, remediate what is honest to remediate, and commit both reports alongside your apis.yml so consumers can see your posture over time. Describe your API well enough to be found, then prove you looked. We index the artifacts you produce — this is one more artifact worth producing.