The document outlines essential practices for API security, emphasizing the importance of investing in security measures due to the vulnerabilities associated with APIs. Key recommendations include implementing strong authentication and access controls, ensuring data validation, and performing regular security assessments. It also highlights common risks, the significance of reducing attack surfaces, and the need for thorough documentation and monitoring.

1. API Security
Doing More With Less
Nir Paz
Product Security @ Standard AI
Nir@Standard.ai

2. Agenda
● Who
● Why invest in API Security?
● Common API Security Risks
● Our Best Practices
○ Authentication and authorization
○ Access control
○ Encryption
○ Data validation
○ Only what’s needed
○ Documentation and Logging
○ API Security Assessment
● Things to take into account
● Recommended tests
● Conclusion

3. Who
● Standard AI - we are building a vision platform that
turns everyday spaces into extraordinary experiences.
● The world’s most advanced autonomous retail
platform.
● Allow shoppers to shop in minutes and check out in
seconds (literally!)

5. Why invest in API Security?
● We use APIs
● APIs lead to data at scale
● APIs are a convenient vector
○ easy to work with
○ funnels data to one point

6. Why invest in API Security?
● Vulnerable
○ Use various protocols and request formats
○ Requires serious design investment (easy to make mistakes)
○ Security isn’t always top of mind when being implemented/designed
● Saves money!
○ Reduces likelihood of a breach (Insurance, IR, brand, downtime, regulation, ransom, etc.)
○ Maintenance, Operation, Support
○ Compute resources

7. Bad design decisions are harder to fix

9. Common API Security Risks
Broken:
- User authentication
- Object-level authorization
- Access another user's account by tampering with an identifier
- Function-level authorization
- Execute commands or access endpoints intended for privileged accounts
* OWASP API Security Top 10 2023RC

10. Common API Security Risks
Not enough:
- Asset management
- Resources and rate limiting
Excessive:
- Injection
- Data exposure
- Mass assignment

11. Our Best Practices
1. Authentication and authorization
2. Access control
3. Encryption
4. Data validation
5. Only what’s needed
6. Documentation and Logging
7. API Security Assessment

12. Authentication and authorization
● Standards (E.g., OAuth 2.0)
● Multi-Factor Authentication
● Random non-guessable IDs (E.g., UUID, ULID)
● Deny all access by default
● RBAC
● Check authorization each time there is a client request to access database

13. Authentication and authorization cntd.
● PLOP (Principle Of Least Privilege)
○ Don’t use Admin account unless necessary
○ Remove default, anonymous, and unused accounts
○ Manage files/folders permissions
○ Isolate and segment environments
○ Limit all external users (guests, vendors, 3rd parties, support)
Bonus: Data classification, limists blast radius, reduces liability

14. Access control
● Requests are processed only after validation check. Else, they never even
reach the application data layer
● Who, what, when, where how much
● View, create, update and delete
● Avoid direct exposure (E.g., Firewall/WAF, Gateway)
○ Also reduces DDoS attacks and code injections
Attack types:
Credential Stuffing DoS / DDoS / Overflow

15. Access control cntd.
● Rate limit, geo-velocity
○ Quota: only X requests / <Time>
○ Throttling: Slow request/reply speed on high volume
○ <Max speed> user must travel to sign in from location A and then location B within <Time>
○ Mitigates brute-force attacks (E.g., DDoS)
● Limit resources
○ Container resources, Payload size limits
Attack types:
DoS / DDoS / Overflow
Credential Stuffing

16. Encryption
● Transport: API requests and responses (use HTTPS)
● Rest: Database layer encryption
Attack types:
Man-In-The-Middle

17. Data validation
● Define schemas, types, and string patterns of all the API requests and
responses
○ Remember error responses
● For object schemas, use the readOnly set to <true> for all properties that
should never be modified
● Validate on server side
○ Mitigate attacks, and anomalies
○ Hinder recon efforts
Attack types:
Injection Cross-Site Scripting (XSS)

18. Only what’s needed
● PLOP (E.g., Principle Of Least Privilege) to reduce attack surface
● Verbosity review
○ Define all outputs including errors
● (Total invoice $) != (the sum of all items in the cart)
● Bonus - Often increases speed too!
Activity type:
Reconnaissance

19. ● Full details (E.g., usage, functions, requirements, location, owner, updates, etc.)
● Pay attention and document all M&A APIs
● Review logs and perform log analysis (uncover anomalies and recon activity as
well as bugs & errors)
○ Avoid sensitive data in logs
● Upon attack use logs to:
○ Scope the damage and build a full report
○ Learn what happened and how
○ Harden and further secure your API
Documentation and Logging
Activity type:
Reconnaissance

20. ● Design Peer Review
○ Poke holes, ask questions, learn!
○ Aim for effectiveness, efficiency, security, elegance
● Dedicated Security Assessment
○ Risks and mitigations table (Category, Risk, Mitigations, Priority, tickets, notes, etc.)
○ Measure risk:
API Security Assessment

21. Things to take into account
● The API Audience
○ Human / Machine, Internal / External, etc.
○ Update cycle (how often, requirements, etc.)
● SOAP vs REST vs GraphQL requirements are different
○ REST is common at small startups mostly for simplicity but lacks built-in security
● Security Tests
○ Before launch/update (end-to-end)
○ Regular tests (specific areas)
● API Key management
○ Secret management
○ Keep only necessary keys

22. Things to take into account cntd.
● 3rd party APIs
○ Dive deep!
● Peer review
○ Easy to wave off
○ Involve your 3rd party partners when possible
● When using tokens ensure expiration time is adequate by
○ Risk Associated with the token leakage
○ Time required for an attacker to produce a valid token
○ Duration of the activity or access grant
● Use one time token when required

23. Things to take into account cntd.
● Can’t do everything at once
○ Build milestones for product features as well as product security
○ Prioritize security features based on the risk assessment exercise and feature availability
○ Ensure prioritization consistency (E.g., don’t drop the ball!)

24. Recommended tests
● Does the API work? (End-to-end tests)
● Can only authenticated users access the endpoints?
○ Tests brute-force entry attempts
● Are users granted access to only the necessary endpoints based on their roles?
● Is the correct information returned in responses?
● Are invalid requests rejected? (including benign!)
● DoS / DDoS / Overflow simulation
○ How does the API deal with legitimate traffic spikes?
● MITM simulation (grab a packet - see what’s inside!)
● Try injecting SQL, NoSQL, LDAP, OS, and other code or script files to requests
● Are all data transfers encrypted? (requests without TLS/SSL blocked)

25. Conclusion
● APIs are very common and present unique vulnerabilities
● API security is more about the context
● Tools are great, but not enough
● Delete everything unnecessary (keys, functions, features, etc.)
● Break down API security into milestones
● Perform Design Review and Security Assessment

26. It’s a wrap!
(^-^)