This document provides an overview of API security from multiple perspectives: API security posture, runtime security, and security testing. It discusses the complex API ecosystem involving various stakeholders. The document also outlines common API attack classes like DDoS, data breaches, and abuse of functionality. Finally, it provides key takeaways that APIs have complex interconnected systems, require coordination across teams, and need to be evaluated from different security perspectives.

1. Peelingthe
Onion
Making Sense of the Layers of
API Security

2. Tableofcontents
Overview
Quick overview of APIs in general
01
APISecurity
Overview of API Security
02
APISecurityLandscape
All the parts that make up the API ecosystem
03
APISecurityConcerns
Items to consider when securing your API
04
Conclusion
Key Takeaways
05

3. Overview
01 Quick overview of APIs in general

4. APISecurity
I believe that API Security is
different enough from ‘traditional’
AppSec that it needs special
attention. I also believe that API use
is only going to grow over time.

5. Who’sthisguy?
● Reformed programmer & AppSec Engineer
● Noname Security -
Distinguished Engineer, Noname Labs
● 14 years in the OWASP community
○ OWASP DefectDojo (core maintainer)
○ OWASP AppSec Pipeline (co-leader)
○ OWASP WTE (leader)
● 22+ years using FLOSS and Linux
● Currently a Go language fanboy
● Ee Dan in Tang Soo Do Mi Guk Kwan
(2nd degree black belt)
● Founder 10Security

6. APIs areSimple…
Wikipedia:
An application programming interface (API) is a connection between computers or
between computer programs.

7. APIs aresimplynotSimple
XML-RPC, SOAP
REST, gRCP, GraphQL
Type
Data
Encoding:
XML, JSON, binary
(protobuf, thrift, …)
INfra
Transport
HTTP(S), HTTP/2,
HTTP/3, QUIC
Load balancer, API
Gateway, Control plane
● Product Teams
● Developers
● Network Admins
● InfoSec / AppSec
● API Gateway Admins
● Security Operations (SOC/IR)
● Mobile Teams
Stakeholders

8. APILandscape https://apilandscape.apiscene.io/

9. APIBreadth anddepth
Over time your APIs will grow:
● Breadth growth
More and more API endpoints get added
● Depth growth
APIs calls create calls to other APIs,
rinse & repeat, especially for microservices

10. CardinalDirections& APIs
North/South traffic
● Traffic from the client to an API usually
through an API gateway
● Originates outside the ‘data center’ or
VPC e.g. external
East/West traffic
● Traffic between internal APIs frequently
bypassing an API gateway
● Originates inside the ‘data center’ or
VPC e.g. internal

11. A BetterDefinitionof an API
From a security controls point of view, an API is really a combination of:
● Method
○ GET, POST, PUT, …
● Hostname
○ example.com
● Path
○ /v2/users/all
GET to example.com/v2/users/all!= DELETE to example.com/v2/users/all
POST to uat.example.com/v2/user/admin!= POST to example.com/v2/user/admin

12. APISecurity
02 Overview of API Security

13. These arenotthe APISyou’relookingfor

14. APISecurityDefined
For the purposes of this talk:
API Security includes determining the state of security from
the perspectives of:
● API Security Posture
● API Runtime Security
● API Security Testing (hopefully continuous)

15. APISecurityPosture
Getting a broad, holistic view of your API landscape including:
● An inventory of every API (the security control definition)
○ Those going through an API gateway
○ Those not going through an API gateway / legacy
○ Internal APIs (east/west)
● Mapping of data going to and from the APIs
○ Classify data traversing the APIs
● Who, What, from Where
○ Who is calling the API?
○ What data are they sending/receiving?
○ Where did the call originate?

16. APIRuntimeSecurity
Understanding the ‘normal’ operations of running APIs including:
● Watching / inspecting traffic to and from the API
○ Inline or out of band
○ Understand all types (REST, gRPC, GraphQL, …)
● Creating behavior based models of traffic for anomaly detection
○ Heuristic, ML, ‘AI’ modeling
○ Continual learning methods
● Thresholds for abnormal traffic, triggering alerts
○ Policies on sensitive or large volumes of data
○ Respond to alerts, manual, semi-auto or automatically
○ Blocking, geo-fencing, deny external traffic

17. APITesting
Assess the security state of a running API
● DAST not SAST
○ SAST isn’t API specific so out of scope
○ Bonus points for continuous or CI/CD friendly
● Understand the APIs available methods
○ Swagger/OpenAPI spec files
○ Recorded traffic (http or other)
○ Automatic understanding based on traffic +1
● Forwarding results to the right people
○ Issue tracker integrations e.g. Jira
○ Ability to see vulnerable requests/responses
○ Ability to re-test specific issue

18. APISecurity
Landscape
03 All the parts that make up the API ecosystem

19. All the world’s a stage,
and all the men and women merely players
API
stakeholders
Wait,
what?

20. Settingthestage

21. Breakingdownthelandscape
WAF Stakeholders: Network Ops, AppSec, Product Teams, …
Web App Stakeholders: Product Teams, AppSec, Marketing, …
Mobile App Stakeholders: Mobile & Product Teams, AppSec, …

22. Breakingdownthelandscape
IdP Stakeholders: Identity and Access, AppSec, InfoSec, …
APIGateway Stakeholders: Gateway Admins, Product, AppSec, …
APIs Stakeholders: Product Teams, AppSec, Marketing, …

23. Breakingdownthelandscape
Cloud Stakeholders: Cloud Team, Product, AppSec, Finance, …
SOC Stakeholders: IR Team, Product Team, InfoSec / AppSec, …

24. APISecurity
Concerns
04 Items to consider when securing your API

25. APISecurityislike anonion,
Lotsoflayers

26. AttackClasses
DDOS - Distributed Denial Of Service
● Network DDOS
○ Traditional flood of traffic
○ Controls are fairly standardized
● HTTP Flood
○ Uses HTTP methods (GET, POST, …)
○ Mirrors legit traffic
○ Single client/customer ‘over consuming’
● Application DOS
○ Consumption attacks (CPU, RAM, …)
○ Can be single or few requests
○ Lack of pagination
Posture
RUntime
Testing

27. AttackClasses
Data breach / leak attacks
● Internal services made public
○ Misconfiguration / Lack of API Gateway
○ Lack of Policy enforcement
● Excessive data exposure
○ Verbose API responses
○ Return full data objects, clients ‘filter’
○ Injection attacks
● Auth-n and Auth-Z weakness
○ Allows account/token takeover
○ BOLA - Client can request others’ data
Posture
RUntime
Testing

28. AttackClasses
Abuse of Functionality
● Business Logic Flaws
○ Normal use-case, unintended use
○ Attackers use your API for their purpose
○ Automatic testing won’t find these
● Examples
○ Spamming using your API
○ Denial of Inventory - products in a cart
○ Carding - validate stolen card data
○ Ad Fraud / Evil SEO
● See “OWASP Automated Threat Handbook”
Posture
RUntime
Testing

29. OWASP APITop10
Risk Posture Runtime Testing
01: Broken Object Level Authorization
02: Broken User Authentication
03: Excessive Data Exposure
04: Lack of Resource & Rate Limiting
05: Broken Function Level
Authorization

30. OWASP APITop10
Risk Posture Runtime Testing
06: Mass Assignment
07: Security Misconfiguration
08: Injection
09: Improper Assets Management
10: Insufficient Logging & Monitoring

31. Conclusion
05 Key Takeaways

32. APIstakeholderSoup
Product Team
AppSec
Onion
Network Ops
Mobile Team
InfoSec
IAM Team

33. Key
Takeaways
Complexity
APIs seem simple on the surface but quickly become a
complex collections of systems with many moving parts
Perspectives
API security has many perspectives which need to be taken
into account when evaluating an API security program
Coordination
Beyond the multiple IT systems, secure APIs require tight
coordination between many different teams
Multifaceted
Protecting APIs includes evaluation from the perspective of
security posture, runtime security and testing

34. CREDITS: This presentation template
was created by Slidesgo, including
icons by Flaticon and infographics &
images by Freepik
THANKS!
Doyouhave anyquestions?
matt.tesauro@owasp.org
https://www.linkedin.com/in/matttesauro/
@matt_tesauro