API breaches are increasing, with over 350 reported publicly since October 2018. The top causes are lack of input validation, rate limiting, data/exception leakage, and authorization and authentication issues. These map to the OWASP API Security Top 10 risks. API-centric architectures expand the attack surface. To address this, security needs to be considered at design time through the API contract, which defines data constraints, authorization policies, logging, and rate limiting. Following best practices like this helps avoid vulnerabilities that are costly to fix later.

1. Addressing OWASP API
Security Top10 starts at
design time
Developer First Platform for API Security
Isabelle Mauny - Field CTO
isabelle@42crunch.com

2. API Breaches are on the rise!
• 350+ breaches reported on apisecurity.io since
Oct. 2018
• And those are just the public ones!
• Recurring Combination of:
• Lack of Input validation
• Lack of Rate Limiting
• Data/Exception leakage
• Authorization issues
• Authentication issues
https://www.datacenterknowledge.com/security/api-attacks-breaches-piling

3. OWASP Top 10 Mapping
• API1 : Broken Object Level Access Control
• API2 : Broken Authentication
• API3 : Excessive Data Exposure
• API4 : Lack of Resources & Rate Limiting
• API5 : Missing Function Level Access Control
• API6 : Mass Assignment
• API7 : Security Misconfiguration
• API8 : Injection
• API9 : Improper Assets Management
• API10 : Insufficient Logging & Monitoring
DOWNLOAD
Data Protection Auth / Authorization Governance/Operations

4. WHY IS THIS
HAPPENING?
4

5. New York
JULY
Australia
SEPTEMBER
Singapore
APRIL
Helsinki & North
MARCH
Paris
DECEMBER
London
OCTOBER
Jakarta
FEBRUARY
Hong Kong
AUGUST
JUNE
India
MAY
Check out our API Conferences here
50+ events since 2012, 14 countries, 2,000+ speakers, 50,000+ attendees,
300k+ online community
Want to talk at one of our conferences?
Apply to speak here

6. API-centric architectures expand the attack surface
Source: https://apisecurity.io/encyclopedia/content/owasp/owasp-api-security-top-10.htm

7. SECURITY IS STILL AN
AFTER THOUGHT!

8. API Security is about protecting data
and requires context
TRADITIONAL SECURITY APPROACHES
ARE NOT WORKING ANYMORE!

9. APPLICATION SECURITY STRUGGLES TO SCALE
APPLICATION
DEVELOPMENT
APPLICATION
SECURITY
450 APIS ON
AVERAGE
1 APPSEC
PERSON FOR
100 DEVS

10. TIME FOR
PROACTIVE
SECURITY
9

11. BAD DESIGN DECISIONS
ARE HARD TO UNDO
DESIGN ISSUES WILL
NOT AUTO-MAGICALLY
FIX THEMSELVES!

12. Know your APIs!
• Security is not a one-size fit all !
• Define which APIs are the most sensitive, for example:
• You’re likely to be in the news if something bad happens
• Your reputation will be affected
• Where is data stored, how it is accessed and by who ?
• What are the potential threats and how do we address
them?
• STRIDE model
• Invented in 1999 by Microsoft, but still relevant
• About knowing the threats and how you mitigate them and
where

13. Approach
•Key to security is to build context at design time, enumerated in the API
contract
Devs
Cyber
Consumer
= = =
Establish an API Contract As The Single Source Of Truth

14. API Contract Design
Data (API3, API6 and API8)
• Build / define the context you need for
security decisions.
• Own your schemas - Inbound and
outbound
• Define data constraints, schema constraints
• Know your PII
• Granted, there are standard ones, but you may have
one called “contraseña” or “numéro_sécu” !
• Don’t forget about :
• Headers
• Error responses
• JWTs (yes, they carry data!)

15. Interface Design
Access Control (API 1, API 2, API 5)
‣ Reduce/Eliminate resources IDs exposure
‣ What is an ID ? Can it be enumerated ? Can we hide it ?
‣ Fine-grained authorization policies
‣ Define external authorization policies (not in the
code…)
‣ True solution to BOLA/IDOR issue
‣ Who has access to what and how
‣ Which operations are we exposing ?
‣ Which ones are critical and require special access ?
‣ Do we have admin-level operations ?
‣ Who can access them ? How ?
‣ Shall this be a separate API all together so that we get
finer control ?

16. API Contract as Context
Positive Security Model for APIs

17. Operating APIs
‣ Invest in a framework for observability /monitoring
‣ Logging cannot be an after thought
‣ Logging needs to be designed! Which data will you log ? Where will it go ?
‣ Design Rate Limiting
‣ Rate limiting is not one size fit all
‣ Design rate limiting, watch for authentication/authorization endpoints.
‣ Design/manage API lifecycle/versioning
‣ Know when to retire APIs

18. CALL TO ACTION!
Use API Top 10 as framework for design and testing
Start worrying about API Security at design time
✓ A vulnerability discovered at production time costs up to 30x more
to solve
Hack yourselves leveraging API contracts
✓ For each functional test, create 10 negative tests
✓ Hammer your APIs with bad data, bad tokens, bad users
Automate Security
✓ Inject Security into DevOps practices and don’t rely on manual
testing of APIs.
✓ Only solution to scale and have avoid human errors
https://www.helpnetsecurity.com/2020/05/20/devops-software-development-teams/
“I think security, in most cases, is not a single
person’s specialization. Security must be a practice
of every member of the team from the frontend
developer to the system administrator (also non
tech roles).”
From: Gitlab DevSecOps report - 2021

19. 18
Thank you!
THE DEVELOPER FIRST
API SECURITY PLATFORM
Continuous Protection for your Digital Business
➡ Subscribe to the apisecurity.io
weekly newsletter for regular
news on breaches, tools and best
practices.

20. New York
JULY
Australia
SEPTEMBER
Singapore
APRIL
Helsinki & North
MARCH
Paris
DECEMBER
London
OCTOBER
Jakarta
FEBRUARY
Hong Kong
AUGUST
JUNE
India
MAY
Check out our API Conferences here
50+ events since 2012, 14 countries, 2,000+ speakers, 50,000+ attendees,
300k+ online community
Want to talk at one of our conferences?
Apply to speak here