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.
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
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
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
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
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
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
