Api security Checklist

 Provide security requirements for front ends: 
for web channels, front-end 
code is typically built using some form of JavaScript such as 
Angular 
or 
React. Users also typically interact with APIs using mobile applications. 
Mobile platforms bring their own uniqueness and security of native mobile 
binaries should also be considered. Similar to ASVS, OWASP also maintains 
the 
mobile ASVS MASVS
that can be a good starting point for defining 
security requirements for mobile device platforms. 
Apple 
and 
Google 
maintain secure coding guidance that can be useful for defining your secure 
coding practices for mobile apps. You should provide guidance on how to 
exchange data securely with back-end APIs, how to authenticate users 
on-device, and how to persist data on-device. 
2. 
 Presume client code and client devices are compromised: 
always operate 
with the mindset that client-code will be reverse engineered, end user 
devices are compromised, and data originating from clients lacks integrity. 
The security risks of these realities are mitigated in varying ways, 
depending where you want to invest time, energy, and budget. Endpoint 
protection can quickly become cost prohibitive, and such solutions are not 
feasible for Internet-facing APIs consumed by the public since you don’t 
“own” consumer devices. For any API, ensure that you are verifying data 
originating from API clients, filter as appropriate for malicious injections 
such as SQLi or JSONi, and escape output to avoid certain types of 
reflected attacks like XSS. 
3. 
 Limit the data you store client-side: 
ideally no sensitive data or intellectual 
property is stored client-side. Realistically, some pieces of data must be 
persisted to provide for an adequate front-end user experience. It’s 
common practice to temporarily persist data such as to maintain session 
Salt I API Security Best Practices I 11 

---

 state or cache for performance. Attackers know this design practice and will 
regularly inspect client-side cache and storage for any remnants of 
sensitive data when reverse engineering apps. Desirable sensitive data 
includes authentication tokens and session data that can be useful to 
attackers attempting session hijacking or account takeover ATO . If you 
must store data client-side, use hardware-backed cryptographically secure 
storage to do so. APIs to interface with device-level hardware and encrypt 
data appropriately are provided by the respective OS vendor and should 
also be provided to engineering teams.
4.