Api security Checklist

 Weigh the pros and cons of session binding: 
binding IP addresses of API 
consumers to session cookies and authentication tokens can provide some 
security benefit. If a bound session identifier or authentication token is 
stolen by an attacker, and the attacker attempts to reuse that authenticated 
session from another machine with a different IP address, the API request 
will be blocked since the request isn’t coming from the original IP address. 
Session binding has an unintended side effect of limiting mobility. If a given 
API consumer uses multiple machines or mobile devices normally, they can 
be forced to authenticate excessively which becomes damaging to UX.
6. 
 Use additional secrets in authorization flows and nonces in requests: 
adding additional secrets in authentication flows helps reduce the risk of 
token interception and replay attacks. OAuth2 provides this type of 
Salt I API Security Best Practices I 22 

---

 protection with 
proof key for code exchange PKCE
. If you are using OAuth 
for authentication in your mobile app, consider employing PKCE to mitigate 
the risk of token interception and replay attacks. PKCE is also slated to 
become mandatory in 
OAuth 2.1 
. Using nonces in requests also helps 
reduce the risk of message replay attacks and cross-site request forgery 
CSRF attacks. You can also use one of the many implementations of 
anti-CSRF mechanisms within code libraries and frameworks. It’s often 
simply a matter of ensuring you’ve enabled the mechanism. 
Runtime protection 
The top 3 recommendations for runtime protection include: 
1. Enable threat protection features of your API gateways and APIM if available 
2. Ensure that DoS and DDoS mitigation is part of your API protection approach
3. Go beyond traditional runtime controls that are dependent on rules, and make 
use of AI/ML and behavior analysis engines to detect API attacks 
Runtime protection, sometimes referred to as threat 
protection, is often delivered through network-based proxies 
like API gateways and WAFs. These mechanisms typically 
rely on message filters and static signatures, which can 
catch some types of attacks that follow well-defined 
patterns but miss most forms of API abuse. Any runtime 
protection you consider deploying should be much more 
dynamic and learn continuously. Runtime protections may 
use signatures for well-known and well-defined attack 
patterns, such as presence of malicious characters that 
indicate injection attack attempts. Runtime protections 
should encompass more than just message inspection and 
filtering though. Protections should be useful for identifying 
misconfigurations in API infrastructure as well as behavior 
anomalies like credential stuffing, brute forcing or scraping 
attempts by attackers. 
Best practices for runtime protection include: 
1.