Api security Checklist

 Use dynamic rate limits and set static rate limits selectively: 
rate limits 
can be useful for restricting consumption of APIs for a smaller set of API 
consumers or partners. Rate limits however often become difficult to scale 
for larger user bases. The issue is prevalent enough that it appears on the 
OWASP API Security Top 10 as API4 2019 Lack of Resources & Rate 
Limiting . You will likely need to relax rate limits, observe traffic consumption 
to inform a baseline, and tighten limits over time. For organizations where 
API consumption can experience spikes, such as in retail and with new 
product launches or seasonable demand, setting effective rate limits can be 
a lesson in frustration. Realistically, rate limiting mechanisms should be 
much more dynamic, granular, and based on actual consumption patterns. 
Setting blanket static rate limits can result in impeded application 
functionality that directly impacts the organization’s business, not to 
mention attackers will throttle their attempts to evade those limits. 
4. 
 Enforce network security via infrastructure, not in code: 
most network 
security controls must exist external to the API code. If ever there was 
evidence that API security is not solely the responsibility of development 
teams or issues were the result of “poor coding practice,” network security 
techniques are a prime example. Transport protection, rate limits, and IP 
address allow/deny lists are almost exclusively defined in infrastructure and 
API mediation mechanisms. One could argue that it might be addressable 
Salt I API Security Best Practices I 17 

---

 using infrastructure-as-code, but that form of code is more likely to be 
owned by network engineering, infrastructure, or API operations teams, not 
application development. 
Data security 
The top 3 recommendations for data security include: 
1. Use encryption selectively and transport protection suffices for most use cases 
2. Avoid sending too much data to clients and relying on the client to filter data 
3. Adjust for threats like scraping or data inference where encryption is not a 
mitigation 
Data security approaches aim 
to provide confidentiality, 
integrity and authenticity of 
data. If your organization still 
includes privacy in the data 
security bucket, then 
anonymization and 
pseudonymization are also in 
scope. Depending on your 
data security goals and 
impacting regulation, 
appropriate techniques for 
protecting data include masking, tokenizing, or encrypting. Many data security 
efforts focus on securing data at rest in a system back-end, such as database 
encryption or field-level encryption. These approaches protect organizations from 
attacks where the data storage is targeted directly. If your API is designed to only 
send encrypted payloads as an additional level of encryption beyond transport 
protection, attackers will still attempt to extract unencrypted data elsewhere, such 
as in memory, from client storage, or other positions within network topology. 
These encryption approaches also do not protect the organization from cases 
where an attacker obtains a credential or authorized session since the data will be 
decrypted for them when accessed through an API. 
Best practices for data security include: 
1.