API security means making sure only the right users and systems can call your API, only for the data they are allowed to see, and only at a sensible rate. The basics are encrypted connections, strong authentication, per-request authorisation, input validation, rate limiting, secret management, logging and regular security testing.
- Every API call must prove who is calling and check what they may do.
- Most serious API leaks come from missing authorisation checks, not from clever hacking.
- Keep keys and tokens out of code, rotate them and limit what each can do.
- Log and monitor calls, and test the API for weaknesses before and after launch.
Why do APIs need their own security thinking?
An API is the doorway that mobile apps, websites, partners and other software use to reach your data and actions. Unlike a web page, it is built to be called by programs, which means attackers can also automate calls at high speed, try thousands of variations and study responses for clues.
Many business apps expose more through the API than the screen shows. A mobile app might display your own order, but the underlying call may accept any order number. If nothing checks ownership, a curious user can read other people's data by changing a single value.
How should authentication work?
Authentication answers who is calling. Use established standards rather than inventing your own: token-based schemes such as OAuth 2.0 and signed tokens like JWT are widely used. Tokens should expire, be tied to a user or system, and be revocable. Never pass credentials in the web address, since addresses are logged in many places.
For server-to-server integrations, use separate keys per partner or system, so that one leaked key can be cancelled without disrupting everyone. Sensitive actions, such as changing bank details, can need a second check. Always serve the API over HTTPS so that tokens and data cannot be read in transit.
Why is authorisation the most common failure?
Authorisation answers what this caller may do. It must be checked on every request, on the server, for the specific record being touched. A logged-in user should only reach their own orders, their own company's invoices or the actions allowed for their role. Hiding a button in the app does not protect the API behind it.
A practical rule is to treat every identifier in a request as untrusted. Look up the record, confirm the caller owns it or has a role allowing access, and only then return it. Also return only the fields the client needs, since sending the whole database row and relying on the app to hide parts exposes sensitive data.
- Check ownership of each record on the server
- Define roles and permissions explicitly
- Return only necessary fields
- Deny by default when a rule is missing
- Test with two different users to confirm separation
What other controls belong in the basics?
Validate all input for type, length and format, which blocks many injection attacks. Apply rate limits to slow down password guessing, scraping and runaway scripts. Use sensible error messages that help developers without revealing internal details such as database names or stack traces.
Manage secrets carefully. API keys, database passwords and signing keys should live in a secrets manager or protected environment variables, not in code repositories or chat messages. Rotate them on a schedule and when staff leave. Keep dependencies updated, because known flaws in libraries are a common entry point.
- HTTPS everywhere, with current security settings
- Input validation and safe database queries
- Rate limiting and quotas per client
- Generic error messages in production
- Secrets stored outside the code and rotated regularly
How do you monitor and test an API?
Log who called what and when, including failed attempts, and send alerts for unusual patterns, such as a single client requesting thousands of different records. Keep logs free of passwords and full card or identity numbers. Good logs let you answer the question of what was accessed if something goes wrong.
Test before launch and regularly after changes. Automated checks catch common mistakes, while a manual review or penetration test finds logic flaws. Keep an inventory of all API endpoints, including old versions and test endpoints that were forgotten, because unmanaged ones are where attackers often get in.
What should Indian businesses add on top?
If your API handles personal data, payments or identity details, check the current data protection rules and any payment security standards that apply to you, with a qualified adviser. Limit what you store, and prefer tokenised payment services over handling card details yourself.
Also think about the vendors in your chain: a payment, SMS or WhatsApp provider is part of your attack surface, so store its keys carefully and restrict where they work. A Plus Solution builds and secures APIs and integrations, and works with security testing teams; regardless of who builds yours, ask for a security checklist at handover.
Frequently asked questions
Is an API key enough for security?
Usually not on its own. Keys identify an application but do not prove which user is acting, and they can leak. Combine them with user-level authentication, authorisation and rate limits.
What is the difference between authentication and authorisation?
Authentication confirms identity, while authorisation decides what that identity may do. Both must be checked on every request.
How often should an API be security tested?
Test before launch, after significant changes and on a regular schedule, such as yearly, depending on risk and data sensitivity.
Do internal APIs need security too?
Yes. Internal networks can be breached, and staff accounts can be misused. Apply authentication and authorisation to internal APIs as well.
Need help with this? Ask us a question about it — we reply within one working day.
