apidays New York 2023 APIs for Embedded Business Models: Finance, Healthcare, Retail, and Media May 16 & 17, 2023 Putting yourself out there - how to secure your public APIs Dan Erez, Architecture Team Lead at AT&T ------ Check out our conferences at https://www.apidays.global/ Do you want to sponsor or talk at one of our conferences? https://apidays.typeform.com/to/ILJeAaV8 Learn more on APIscene, the global media made by the community for the community: https://www.apiscene.io Explore the API ecosystem with the API Landscape: https://apilandscape.apiscene.io/

1. Putting yourself out there:
Securing APIs
1 May 2023
Dan Erez

3. 2 API Conference 2023
Who am I?
• Lead Architect
• +20 years of software development
• Native language: Java
• Enterprise Architecture
• Cloud Architecture
• Serverless
• Speaker
• Trying to innovate…See in medium
(dan.erez)
2

4. • API Security – Why should we
care?
• Some war stories
• Common (and uncommon)
security measures
• Future of API/API security
• Q&A
Agenda
3 API Conference 2023

5. 4 API Security
• - Any end point one can call to
activate application code
• - Can be M2M/S2S (Machine to
Machine, Service to Service)
• - Or called from a browser
• - Or manually (e.g. via PostMan,
Curl etc.)
What do I mean when I say API?
4

6. 5 API Security
API Timeline
5

7. 6 API Security
• Everybody has them (MSA, legacy)
• Main way to communicate (BE->BE, FE->BE)
• High visibility → A wide attack surface
• Not easy to defend…
APIs Nowadays
6

8. 7 API Security
• DDD
• API = Business Service
• API = Contract
• Enables faster development:
• Define business flows
• Define interfaces
• Implement API+Mock
• Validate flows – do they make sense?
• Check out ‘Postman Flows’
API-First Design
7

9. 8 API Security
• More than 7000 applications
• 2000 already moved to Azure
• High degree of new connectivity (Cloud<->Cloud, Cloud<->On
Prem)
• Internal and External, new and upgraded APIs
• ‘API Sprawl’-> less visibility, harder to manage, larger attack
surface, less standardization
Our Story
8

10. 9 API Security
We’re on it!
9

11. 10 API Security
Risks…
10
Just yesterday, T-Mobile revealed that a threat actor stole
the personal information of 37 million postpaid and prepaid
customer accounts via an exposed API (which they exploited
between November 25, 2022 and January 5, 2023). The vendor
didn’t share how the hackers exploited the API.

12. 11 API Security
Risks…
11

13. 12 API Security
Security Measures
12

14. 13 API Security
Discovery
13
• Problem: Not all the APIs are known and classified
• Shadow APIs: APIs no one knows about
• Zombie APIs: Unused API
• What data is being sent?
• Do we want to limit users? Roles? Rate?
• Solution:
• Find all exposed APIs
• Remove unused APIs
• Document Shadow APIs
• Classify the sent data

15. 14 API Security
Standardization
14
Problem:
• - When a company grows/transforms, standardization is harder
• - Harder to maintain and protect (e.g. by applying tools)
Solution:
• - Define reasonable standards
• - Enforce standards (using tools)

16. 15 API Security
Encrypt!
15
Problem:
- Old systems still use non encrypted
interfaces
- Or use older, less secure, standards
Solution:
• Apply Zero Trust standards and always
encrypt
• Latest TLS (1.3)
• Two-way TLS (mTLS)

17. 17 API Security
No General APIs!
17
Problem:
- General purpose APIs expose too much data
(‘getCustomers’)
Solution:
• - Be specific, It’s more secure
(“getEnterpriseCustomers”)
• No full DTOs - You’re giving away TMI

18. 18 API Security
What about GraphQL?
18
Problem:
• - Defaults are not secured (e.g. introspection)
• - No built-in authorization mechanism
• - Deep requests can take time
Solution:
• - Block Introspection in production
• - Add authorization
• - Limit size and depth

19. 19 API Security
GraphQL Evil Query
19
query {
repository(owner:"rails", name:"rails") {
assignableUsers (first: 100) {
nodes {
repositories (first: 100) {
nodes {
assignableUsers(first: 100) {
nodes {
repositories(first: 100) {
nodes {
# Iterate until the server is exhausted
}
}
}
…
One round: 5 users * 10 repositories = 50 objects
Two rounds: 50 objects * 5 users * 10 repos = 2500 objects
Three rounds: 2500 objects * 5 users * 10 repos = 125,000 objects
Four rounds: 125000 objects * 5 users * 10 repos = 6,250,000 objects

20. 20 API Security
Over privileged APIs
20
Problem:
- Things change over time
- Do all those users need all those
permission
Solution:
•Automate periodic checks (Well done
AT&T!)
•Consider new, more specific APIs

21. 21 API Security
Dos, DDos
21
Problem:
• - Too many requests concurrently
• - Example: AWS attack in February 2020
- 2.3 Terabits per second!
- Hackers hijacked LDAP servers
Solution:
• - Rate Limiting (Using WAF or API Gateway)
• - Limit by IP, User, API Key etc.
• - CORS

22. 22 API Security
OWASP is your friend!
22
Problem:
• - Where should I invest my API protection energy?
• - What are the common attacks?
Solution:
• - Check OWASP Top 10 (https://owasp.org/www-
project-api-security/)
• - Winners:
 Broken Object Level Authorization
 Broken User Authentication
 Excessive Data Exposure

23. 28 API Security
Tokens (JWT)
28
Problem:
• - Quick and secure way to identify and
authorize.
• - We don’t want our user/pwd travelling all over
Solution:
• -Use tokens!
• -OAUTH2, OIDC
• -Better: Opaque tokens
• atfqIQW3HXqF1hkot1e6hJDIj4qHnwTEUXiGJFf09kS
RHhlx6wlDz5GZncAr99HfM7FUbDQlUg73MapL0TJ2I

24. 29 API Security
Payload Challenges
29
Problem – Evil Payload:
• -Very large requests
• -SQL Injection
• -Evil info
• -Large attachments
• -Viruses
Solutions
• -Size limiting (Payload and attachments)
• -Data validation
• -Virus scanning

25. 30 API Security
Patch Everything…
30
Problem:
• - New OS/libs vulnerabilities are found every week
• - Indirectly affects your API (e.g., stolen identity)
Solution:
• - You can run on VMs and work hard
• - Or use App Service, Kubernetes, serverless…

26. 32 API Security
Monitoring & Tracking
32
Problem:
• - What if something happened?
• - Who did what? What data was stolen
or corrupted?
Solution:
• - Audit!
• - Track usage... and alert on suspicious
usage/rate!
• - Future: ML based tracking
• - Train for disaster…

27. 33 API Security
• One entry point! Narrow the attack
surface
• Easier to standardize
• Great place to do some checks and rate
limiting
• Let developers focus on business
• But – who said the attacker would pass
through the Gateway?
What about API Gateways?
33

28. 34 API Security
• DMZ – check messages (size, sql injection etc.) – HTTP level
security
• Inside – Data checks
API Firewalling
34

29. 35 API Security
Shift Left
35

30. 36 API Security
• Test, and not just functionality:
• Injections
• Large inputs
• Revealing error messages
• Some tools: Bug Bounty, Invicti, Astra
Pentest, AppKnox and more
• Call the pros: Professional Pen test
Test/Penetrate
36

31. 37 API Security
Key Takeaways
37
• Follow the latest threats
• Narrow the attack surface
• Use proper, updated, defenses
• Penetration tests!
• GOTO 10

32. 38 API Security
• More ML and dynamic defenses
• Automation of standards enforcement
• APIOps
• Let the product guys in (Entor.io)
• Conversational APIs
• More streaming APIs
The Future of APIs
38

33. Too shy to ask here?
• Dan Erez in LinkedIn
• dan.erez@intl.att.com
• Feel free to consult
(Micro Services, Serverless, Clouds, Whatever…)
Q&A & Thank you!
39 API Conference 2023