Api security Checklist

 Pentest APIs periodically or as mandated by regulation: 
penetration 
testing, specifically application-scoped and API-scoped engagements, 
involve a mixture of automated and manual testing techniques. It should be 
Salt I API Security Best Practices I 9 

---

 handled by those with appropriate subject matter expertise. If a pentesting 
firm is offering junior level testers or running VA scanners to analyze your 
most critical APIs, look elsewhere. The interval at which you should or must 
perform pentests is sometimes outlined by corresponding regulation. 
Absent compliance or regulatory requirement, it is advisable to coordinate 
pentest engagements quarterly, semi-annually, or annually for your most 
critical or exposed APIs.
6. 
 Augment testing further with bug bounties if you want more assurance: 
some organizations also opt to augment their security testing capacity 
further with bug bounty programs that are public or private, and possibly 
coordinated through a crowd-sourced platform. Bug bounty programs can 
be the subject of debate, and bounty services often provide no guaranteed 
testing methodology as typically seen with a qualified pentesting firm. 
Typically, you pay for results, not the engagement and testing activity itself. 
Still, using the “power of the crowd” continuously with bug bounties can be 
useful for uncovering API issues that even the most seasoned security 
experts are unable to find. 
Front-end security 
The top 3 recommendations for front-end security include: 
1. Draft security requirements for front-end code including JavaScript, Android, 
and iOS 
2. Store minimal or no data client-side since it is prone to attack and reverse 
engineering 
3. Explore client-side code protections if you’ve secured back-end APIs 
Organizations often attempt to secure and harden the front-end code that is 
installed on user devices, but this proposition can be difficult given what is in the 
realm of control of the organization. For mobilized employee apps, this approach 
may still be technically feasible for bring your own device BYOD and 
corporate-owned, personally-enabled COPE scenarios. However, for mobile apps 
destined for customers, patients, or citizens, an organization has little control over 
end user devices where client-side code protections are often circumvented. 
Securing the front-end application, or the API client, that depends on back-end 
APIs for functionality and data can be useful as part of a layered security approach, 
but such an approach still has downsides. Some pitfalls of client-side approaches 
you should be aware of include: 
Salt I API Security Best Practices I 10 

---

 ● 
Client-side code is readily decompiled or disassembled to uncover and 
understand API endpoints, including any protections you embed in that 
code. 
● 
Client-side code controls are not feasible for direct API or machine to 
machine communication 
● 
Techniques like certificate pinning, while sometimes recommended, can 
complicate certificate rotations, app updates, and back-end traffic 
inspection.
● 
Client-side mechanisms can slow down release cadences for mobile apps 
and complicate public app store vetting processes. 
● 
Client-side challenges like CAPTCHA are readily bypassed or farmed out to 
solving services. Client-side behavior analytics and machine tracking 
inadvertently create privacy concerns. 
Best practices for front-end security include: 
1.