This document discusses lessons that can be learned from API data breaches and recommendations for improving API security. It analyzes examples of past breaches and common factors like lack of authorization checks, exposure of sensitive data, and poor authentication. The document advocates for a holistic approach to API security that involves cross-team communication, visibility into the entire API landscape, enforcement of security policies, and inclusion of application-layer defenses. Recommendations include implementing authentication, authorization, input validation and output sanitization in code, and using a commercial tool to monitor API configurations and detect anomalies.

1. WHAT ‘OUTLIERS’ CAN TEACH US
ABOUT API BREACHES
JEREMY SNYDER, FOUNDER & CEO
JEREMY@FIRETAIL.IO

2. PREVENTING
FUTURE
API DATA
BREACHES,

3. RECOMMENDE
D READING

4. Source: Back Bay Books, Amazon.com, Malcolm Gladwell

5. Source: Akamai State of the Internet Report 2021

6. Source: Michel Guilliand, Wikimedia Commons

7. WHAT HAPPENED?
KOREAN AIR FLIGHT 801
August 5, 1997, Seoul (Gimpo / GMP) to Agana, Guam (GUM)
List of problems on the day
Captain initially scheduled to fly to Dubai, reassigned due to lack of rest
Turbulence just outside Guam due to heavy rains, and additional rain on
Guam between the coast and airport
Captain wanted to use ILS but it was not functional at GUM
Communication breakdown; navigator informed of being off-course
and inoperative ILS, but ignored by Captain

8. SO WHAT DO
WE SEE FROM
THIS?

9. COMMON THREADS
ANALYSIS RELEVANT FOR API DATA BREACHES
Multiple things went wrong
Technical issues + non-technical issues
Lack of team communication / coordination
Internal / external parties

11. BREACH DATA ANALYSIS
EXAMPLES OF BREACH LOGIC AROUND
AUTHORIZATION
Authenticates once, but then doesn’t require subsequent
authorization to access additional functions
Sequential numbering made scraping very easy
Conclusions:
Authentication ≠ authorization
Must be done server-side
Must be with EVERY call
Principal + resource + action; either all map to YES, or it’s NO
Source: https://techcrunch.com/2021/05/05/peloton-bug-account-data-leak/

12. “VULNERABILITIES IN
APPS HANDLING API
DATA ARE THE DIRECT
CAUSE OF THESE
BREACHES. NOTHING
ELSE IS TO BLAME.” –

13. BREACH DATA ANALYSIS
EXAMPLES OF BREACH LOGIC AROUND AUTH
N/Z +
API URL landed in Google SERP
API did not require authentication token
API did not check for authorization
API allowed CRUD functions
Conclusions:
Combo network configuration + more
Poor API design on auth-N/Z
Source: https://techcrunch.com/2021/05/13/lemonade-insurance-bug-exposed-

14. ALMOST ALL
BREACH
EVENTS ARE
MULTI-VECTOR

15. BREACH DATA ANALYSIS
EXAMPLES OF BREACH AROUND SERVER &
DATA HANDLING
Server gave overly verbose errors
Enumeration exposed routes
Found undisclosed graphQL endpoint
GraphQL endpoint allowed “select *”
Conclusions:
Poor server config
Non-declarative API model
Excessive exposure
Source: https://samcurry.net/hacking-starbucks/

16. BREACH DATA ANALYSIS
EXAMPLES OF BREACH AROUND NETWORK /
DATA / AUTH
API made public with DNS / network
configuration change
API had poor authN
Incremental account IDs
Conclusions:
Poor network change mgmt
Bad data handling
Easy API access
Source: https://techcrunch.com/2022/09/22/optus-australia-data-breach/

18. BREACH DATA ANALYSIS
ATTACK VECTORS FOR APIS

19. BREACH DATA ANALYSIS
BUT THERE’S MORE…

20. BREACH DATA ANALYSIS
DISCUSSION AROUND MULTI-VECTOR
CONCLUSIONS
Almost all cases, more than one thing went wrong
Sequential numbering + no server-side authZ
No authZ + full data records returned (trimmed by client)
3rd party API access keys discovered + lack of encryption
Using common IDs (like VIN or SSN) as authN tokens + second
factor

21. BREACH DATA ANALYSIS
OTHER NOTES AROUND ATTACK VECTORS
TRACKED
Enumeration – lab environment with hits within 5 min, return
callers, 90%+ traffic is probing (git.config, /.env, etc)
Data Exposure – returning too much data; leaving it to the client to
trim or remove
Injection – not super common, roughly ~10% of cases
Governance - general term, can refer to configuration in a cloud
environment, private -> public API, etc

23. BREACH DATA ANALYSIS
SYSTEMIC FLAWS CAN BE ATTACKED
SYSTEMATICALLY
These flaws tend to affect the entire API / app logic
In responsible disclosures, researchers have often performed very
large POCs
Average number of records per breach is in the millions, but has
actually come down (more breach events)

24. BREACH DATA ANALYSIS
SOME OTHER OBSERVATIONS
Not industry-specific - APIs are everywhere
Not geography-specific – APIs are everywhere
But some industries have had a huge breach impact recently
Manufactoring (automotive)
Technology (software)
Hospitality (airlines, hotels, rental cars)

25. TRACK OUR RESEARCH
DATA AND ANALYSIS SHARED ONLINE
FireTail’s API Data Breach Tracker:
https://firetail.io/api-data-breach-tracker

26. SO WHAT ARE
API SECURITY
RECOMMENDA
TIONS?

27. CORE PRINCIPLES OF API SECURITY
FIRETAIL
VISIBILI
TY
OBSERVABI
LITY
POLICY AUDIT
DISCOVE
RY
ENFORCEM
ENT
Authentication,
authorization, validation,
sanitization in code
Commercial version sends
configuration and success /
failure events to cloud
backend
Full view of API landscape
across IT fleet
Finding APIs not running
FireTail library via network
traffic, code repos & cloud
APIs
APIs can be analyzed for
configuration settings and
security policy. API security
posture management
Full and centralized audit
trail of all APIs with FireTail
library implemented. Search
and set alerts.

28. INCLUDE THE
APPLICATION
LAYER

30. Source: Back Bay Books, Amazon.com, Malcolm Gladwell

31. WHAT SHOULD WE DO?
AN OUTLIER APPROACH TO API SECURITY
Make sure that communication is cross-team, and that no team has a
blanket veto
The company that starts earliest has the best chance of success
But remember – it’s in your peer group
Do your 10,000 hours!

32. THANK YOU!
JEREMY@FIRETAIL.IO
https://firetail.io
START A FREE TRIAL WITH US SOON TO GET FULL API VISIBILITY & SECURITY