Home / Knowledge hub / API
Knowledge hub
API
The part of your application other software talks to, not a person.
What it means
An API is the part of your application that other software talks to, rather than a person with a browser. Your mobile app uses one. Your website almost certainly does too, and so does every integration a customer has built on you.
It speaks in plain requests and structured answers instead of pages. Anyone can send those requests by hand, so the interface you designed is not the only way in.
Why it matters
Most products keep their real business rules behind an API, which is why an API with weak checks leaks more than a website ever could. There is no interface to hide a button in. One endpoint that forgets to check ownership hands over the whole table, a record at a time.
You also get less warning. A person browsing leaves a trail of pages. Software making requests looks the same whether it is your mobile app, a customer's integration, or somebody counting through record numbers at a steady pace.
Documentation drifts as well. The endpoint list in your docs and the endpoint list your server answers on stop matching within a release or two.
How it shows up
The classic pattern is an endpoint that returns a record because you asked for it by number, without checking the record belongs to you. Close behind sits an endpoint that accepts fields it was never meant to accept, such as a role or a balance in an update.
Look at what the API returns rather than what the screen shows. A response carrying a full user object, with internal flags and other people's identifiers, leaks whether or not the interface displays it.
Cyberlop tests web applications and the APIs behind them, logged in as each role you give us. See what the platform covers.
Questions people ask
API, answered
Can someone explain what an API actually is?
It is the door your software opens for other software. A person uses your website. A program uses your API, sending a request and getting structured data back.
Same product, same rules, different front door. That is why it needs testing of its own.
We use HTTPS. Why does the API need security on top of that?
HTTPS protects the data while it travels. It says nothing about whether the caller was allowed to ask for what they asked for.
An encrypted request for somebody else's invoice is still a request for somebody else's invoice, and it arrives perfectly intact.
Why can't customers just connect to our database directly?
Because a database does not know your business rules. It answers queries. Your API is the place where you decide that this customer may see these rows and nothing else.
Give people direct database access and every rule you rely on becomes optional.
Is it safe to put an API key in the URL?
Better not to. URLs end up in browser history, server logs, proxy logs and the referrer header of the next page. A key in a query string leaks into places nobody planned for.
Send it in a header, and rotate any key that has ever travelled in a URL.
How do I make sure only our mobile app can call the API?
You cannot, not fully. Anything shipped inside a mobile app can be pulled back out of it, including keys and pinned certificates. People do this routinely.
Design as though every caller might be a script. Authenticate the user rather than the app, check permissions on each request, and limit the rate.
Sources
Where this comes from
Related
Terms that sit next to this one
BOLA
An API returns a record just because you asked for it by number.
IDOR
Changing an id in a request and getting back someone else's record.
GraphQL
One API endpoint where the client asks for exactly the fields it wants.
Mass assignment
When the fields in a request get written straight onto a record.
Authorization
Deciding what a proven user is then allowed to do.
How many endpoints do you ship?
We test the API behind your product, not only the pages, logged in as each role you have. Every finding arrives with the request, the response and the line responsible. Send us your endpoints.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.