We are using an outsourced development team and part of their work is to create APIs for various integrations.
At the moment the APIs are only secured via an API key.
I know there are more secure methods like:
- Gateways
- Certificates
- oAuth
But we don't know which ones are most appropriate for our situation
We require assistance in reviewing our use case for APIs, and develop a procedure or policy for securing these APIs more strongly.
1.
You need to protect your web services from 2 types of malicious actors:
1.1) Actors who want to hack your web services.
1.2) Actors who want to abuse your web services.
2.
The attack vector of type 1.1 malicious actors will most likely not focus on authentication, but on post-authentication scenarios: simply because there are more potential vulnerabilities (or attack vectors) in post-authentication scenarios.
For example, if a particular API request allows SQL injection, it does not matter what authentication method was used before.
To protect against type 1.1 malicious actors, I can perform a full security audit of the codebase of your services.
3.
Type 1.2 malicious actors will not hack your services: they will abuse them.
I can implement anti-abuse protection in your web services:
3.1. Separation of keys into «test» and «live» environments
3.2. Key rotation and revocation
3.3. Restricted API keys: limiting rights and access
3.3.1) For example, Stripe supports restricted keys that specify what specific resource types (payments, fees, refunds, webhooks, etc.) and actions those keys can access.
3.3.2) GitHub uses «fine-grained personal access tokens» for the same purpose, allowing an even more granular definition of which specific repositories and actions (read, write, manage, etc.) the token can access.
This makes it possible to issue a token for a specific task rather than for the entire account.
3.4. Logging and monitoring of API calls
Maintain a detailed log of API calls (including information about which key was used).
3.5. Rate-limiting mechanisms
Limit the frequency of requests to your infrastructure.
3.5.1) For example, OpenAI (as well as many cloud services) tracks the request rate (number of requests per second/minute) and can return a 429 (Too Many Requests) error if a threshold is exceeded.
This protects against DDoS attacks or sudden bursts of requests from stolen/compromised keys.
3.6. Monthly and daily usage limits
3.6.1) For example, OpenAI sets quotas or limits for each account on the number of requests and/or tokens that can be used per day or within a certain time period.
If the volume of requests suddenly exceeds the allowed level, the system can temporarily block or suspend access.
3.7. Built-in fraud prevention mechanisms
Is is necessary to analyze transactions and API user behavior to detect fraudulent patterns.
3.8. Automatic API key invalidation when certain events occur
This can be implemented via triggers that suspend or limit access, and then generate a notification.
3.9. Anomaly monitoring
If the API key is suddenly starts being used from an unusual region or with an unusually high number of requests, additional checks can be triggered to suspend requests until it is confirmed that this is indeed legitimate traffic.
3.10. Web Application Firewall (WAF)
This provides additional protection against:
3.10.1) Scanning and brute-force attacks (e.g., token guessing).
3.10.2) DDoS attacks on the API.
3.10.3) Known signatures of malicious requests.
3.11. Linking usage to a payment card
This creates an additional barrier: it is not enough for a fraudster to steal an API key — a valid payment method is also required to divert significant resources.
3.12. Integration with GitHub Secret Scanning
GitHub provides a service that automatically scans repositories for published service keys.
3.13. Key prefixes
Using a key prefix (e.g. , sk-) provides an additional way to quickly find compromised keys when scanning arbitrary text files or logs.
3.14. Restriction by request source
Due to such restrictions, it is not enough for attackers to simply obtain the key themselves — they also need to come from the correct IP or have a signed application with a valid certificate.
For example:
3.14.1) HTTP Referrer (URL): the key will only work when called from a specific domain (or a list of domains).
3.14.2) IP addresses: the key will only work if the request comes from specific IPv4/IPv6 addresses or subnets.
3.14.3) Android applications (package and SHA1 certificate): the key will only work for a specific application with the specified package and certificate fingerprint.
3.14.4) iOS applications (bundle ID): similar to Android, but for the iOS bundle identifier.
3.15. Temporary tokens and HMAC signatures
This scheme makes it more difficult to intercept or «replay» requests because the signature is tied to the exact time and content of the request.
Any change to the headers, body, or timestamp invalidates the signature.
For example, Amazon Web Services calls this technology «AWS Signature Version 4».