# API Security for Developers

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1693745563704/ce0abd02-8e12-4e66-ac98-8771987bcda6.png align="center")

Before understanding the best practices we should first understand why it is important for developers to keep APIs secure. This is because:

1. From banks, retail and transportation to IoT, autonomous vehicles and smart cities, APIs are a critical part of modern mobile, SaaS and web applications and can be found in customer-facing, partner-facing and internal applications.
    
2. By nature, APIs expose application logic and sensitive data such as Personally Identifiable Information (PII) and because of this have increasingly become a target for attackers.
    
3. Without secure APIs, rapid innovation would be impossible.
    

### **Broken object-level authorization**

* Implement authorization checks with user policies and hierarchy.
    
* Do not rely on IDs that the client sends. Use IDs stored in the session object instead.
    
* Check authorization for each client request to access the database.
    
* Use random IDs that cannot be guessed (UUIDs).
    

### **Broken authentication**

* Check all possible ways to authenticate to all APIs.
    
* APIs for password reset and one-time links also allow users to authenticate and should be protected just as rigorously.
    
* Use standard authentication, token generation, password storage, and multi-factor authentication (MFA).
    
* Use short-lived access tokens.
    
* Authenticate your apps (so you know who is talking to you).
    
* Use stricter rate-limiting for authentication, and implement lockout policies and weak password checks.
    

### **Excessive data exposure**

* Never rely on the client to filter data!
    
* Review all API responses and adapt them to match what the API consumers need.
    
* Carefully define schemas for all the API responses.
    
* Do not forget about error responses, define proper schemas as well.
    
* Identify all the sensitive data or Personally Identifiable Information (PII), and justify its use.
    
* Enforce response checks to prevent accidental leaks of data or exceptions.
    

### **Lack of resources and rate limiting**

* Define proper rate limiting.
    
* Limit payload sizes.
    
* Tailor the rate-limiting to match what API methods, clients, or addresses need or should be allowed to get.
    
* Add checks on compression ratios.
    
* Define limits for container resources.
    

### **Broken function level authorization**

* Do not rely on the client to enforce admin access.
    
* Deny all access by default.
    
* Only allow operations to users belonging to the appropriate group or role.
    
* Properly design and test authorization.
    

### **Mass assignment**

* Do not automatically bind incoming data and internal objects.
    
* Explicitly define all the parameters and payloads you are expecting.
    
* Use the `readOnly` property set to `true` in object schemas for all properties that can be retrieved through APIs but should never be modified.
    
* Precisely define the schemas, types, and patterns you will accept in requests at design time and enforce them at runtime.
    

### **Security misconfiguration**

* Establish repeatable hardening and patching processes.
    
* Automate locating configuration flaws.
    
* Disable unnecessary features.
    
* Restrict administrative access.
    
* Define and enforce all outputs, including errors.
    

### **Injection**

* Never trust your API consumers, even if they are internal.
    
* Strictly define all input data, such as schemas, types, and string patterns, and enforce them at runtime.
    
* Validate, filter, and sanitize all incoming data.
    
* Define, limit, and enforce API outputs to prevent data leaks.
    

### **Improper assets management**

* Keep an up-to-date inventory of all API hosts.
    
* Limit access to anything that should not be public.
    
* Limit access to production data, and segregate access to production and non-production data.
    
* Implement additional external controls, such as API firewalls.
    
* Properly retire old versions of APIs or backport security fixes to them.
    
* Implement strict authentication, redirects, CORS, and so forth.
    

### **Insufficient logging and monitoring**

* Log failed attempts, denied access, input validation failures, or any failures in security policy checks.
    
* Ensure that logs are formatted so that other tools can consume them as well.
    
* Protect logs like highly sensitive information.
    
* Include enough detail to identify attackers.
    
* Avoid having sensitive data in logs — if you need the information for debugging purposes, redact it partially.
    
* Integrate with SIEMs and other dashboards, monitoring, and alerting tools.
    

**Contact Us**  
[LinkedIn](https://www.linkedin.com/in/david-opara-133a6820b/?lipi=urn%3Ali%3Apage%3Ad_flagship3_feed%3B9z0e7zxvSq%2BE38geb0193g%3D%3D) [Gmail](http://zalparus22@gmail.com)