View on-demand: https://wso2.com/library/webinars/api-security-best-practices-and-guidelines/ Modern enterprises are increasingly adopting APIs, exceeding all predictions. With more businesses investing in microservices and the increased consumption of cloud APIs, you need to secure beyond just a handful of well-known APIs. You will need to secure a higher number of internal and external endpoints. At the same time, security itself is a broad area and vendors implement a number of seemingly similar standards and patterns, making it very difficult for consumers to settle on the best option for securing APIs. The sheer number of options can be very confusing. There is much to learn about API security, regardless of whether you are a novice or expert and it’s extremely important that you do because security is an integral part of any development project, including API ecosystems. This webinar will deep-dive into the importance of API security, API security patterns, and how identity and access management (IAM) fit in the ecosystem. DURING THE WEBINAR, WE WILL COVER: Managed APIs OAuth 2.0 and API security patterns Introduction to WSO2 Identity Server How we align with OWASP API security guidelines

1. API Security Best Practices and
Guidelines
Thursday, October 22, 2020

2. Hello!
Omindu Rathnaweera
Thanuja Jayasinghe
Associate Technical Lead
thanuja@wso2.com
omindu@wso2.com
Technical Lead

3. About ‘API Security and Beyond’ Webinar Series
3

4. 4
600+ Employees
50% Engineering
500+ Customers
Around the world
(129 New in 2019)
Open Source
Flexible Deployment,
Faster Time To Market
Founded in 2005
Backed by Cisco and
Toba Capital
Global Presence
Colombo, New York,
London, Mountain View,
São Paulo, Sydney, Berlin,
Mexico, Italy
20% YOY Growth
$49.9M total ARR
$10.47M ARR from WSO2 Identity
Server (as of March 31, 2020)

5. 5
Addresses full API lifecycle
management operations. Open,
extensible, customizable.
200K+ APIs for 20K+ Orgs
Hybrid integration platform for
quick, iterative integration of any
application, data, or system.
6 Trillion Transactions/yr
Federates and manages identities
across both cloud service and
enterprise environments.
250M+ identities managed
WSO2 API MANAGER WSO2 IDENTITY SERVERWSO2 ENTERPRISE INTEGRATOR
WSO2 Integration Platform

6. 6
WSO2 Identity Server is a strong performer
among the 13 CIAM providers that matter
most according to Forrester Research, Inc..
● Highest scores possible in customer
authentication, self service, business
integration, reporting and dashboarding, and
privacy & consent management in the
Product Offering category
● Highest scores for commercial model in
strategy and authentication plans
WSO2 Identity Server has been recognized as a strong performer

7. 7
Key Capabilities
● Identity federation and SSO
● Identity bridging
● MFA and adaptive authentication
● Managing access to APIs
● Consent management
● Accounts management
● Progressive profiling
● RESTful APIs for integration
● Regulatory compliance
● Identity analytics
WSO2 Identity Server Capabilities

8. APIs & Security

9. ● A substantial growth in API economy
● Businesses are leaning towards an API-first strategy
● “API traffic amounts to 83% of all web traffic” - Akamai
● APIs are susceptible to attacks now more than ever
The State of APIs
9

10. APIs will become the
#1 Attack vector by 2022
10

11. ● API access control and privacy, as well as the detection and remediation of
attacks on APIs
● Lack of security may lead to
⦿ Data breaches
⦿ Data manipulation
⦿ Downtime
API Security - What & Why
11

12. ● Who is the intended audience
⦿ Public
⦿ Employees
⦿ Partners
● Who is accessing
⦿ A human user
⦿ A system
● How are the APIs accessed
⦿ Web app
⦿ Mobile app/SPA
API Security - Things to Consider
12

13. ● Trust bootstrap
⦿ Direct
⦿ Brokered
● The data
⦿ Collection
⦿ Exposure
API Security - Things to Consider
13

14. OWASP API Security Top 10

15. OWASP API Security Top 10
15
● Focuses on the top 10 most common vulnerabilities in API security

16. ● Attacker substitutes ID of their resource in API call with an ID of a different
user resource. Access will be granted if authorization checks are not in place
1. Broken Object Level Authorization
16
GET /user/1001
GET /user/1002
{
“name” : “Attacker”,
“phone” : 8931883
}
{
“name” : “Another User”,
“phone” : 3433896
}

17. 1. Broken Object Level Authorization
17
● Mitigation
⦿ Set up policies for user specific authorization checks
⦿ Rely on the session object and not the ID sent by the user
⦿ Check authorization when access a data source based on request
⦿ Randomize IDs

18. 2. Broken Authentication
18
● Incorrectly implemented API authentication allowing attackers to assume
other users’ identities.
Authorization: Bearer expired-token
GET /user-profile?user=sam
{
“name” : “Sam”,
“phone” : “8931883”,
“email” : “sam@foo.com”,
}

19. 2. Broken Authentication
19
● Mitigation
⦿ Validate authenticate mechanisms in all APIs
⦿ Use of industry standards and best practices
⦿ Short-lived access tokens
⦿ Client authentication
⦿ Enforce authentication policies

20. 3. Excessive Data Exposure
20
● APIs exposing data which is not needed for clients, expecting the client to do
the filtering. Attacker goes directly to the API and has it all.
GET /user-profile?user=sam
{
“name” : “Sam”,
“phone” : “8931883”,
“salary” : “100000”,
“account-no” : “1286-4499-0275”
}

21. 3. Excessive Data Exposure
21
● Mitigation
⦿ Don’t expect the client to filter data
⦿ Validate all the API responses including errors
⦿ Have a defined schemas for all the API responses
⦿ Be mindful about sensitive or PII information

22. ● API is not geared to handle excessive amount of requests or payload sizes
4. Lack of Resources and Rate Limiting
22
.
.
.

23. 4. Lack of Resources and Rate Limiting
23
● Mitigation
⦿ Limit request rates and payload sizes
⦿ Impose rate limits to API methods, application and users
⦿ Integrate with DDoS protection services
⦿ Impose resource limits on containers

24. ● API expects clients to use user level or admin level APIs. Attacker can figure
out the admin API methods and invokes them directly.
5. Broken Function Level Authorization
24
GET /users/me
GET /admins
{
“name” : “Attacker”,
“phone” : 8931883
}
{
“username” : “admin-user1”,
“email” : “admin1@foo.com”
} . . .

25. 5. Broken Function Level Authorization
25
● Mitigation
⦿ Don’t rely on app to enforce admin access
⦿ Deny by default
⦿ Role based access control
⦿ Have a properly authorization model

26. ● Binding request input to data models, without proper input filtering, can lead to
mass assignment where attackers can modify object they are not supposed to
6. Mass Assignment
26
GET /user-profile?user=sam
{
“name” : “Sam”,
“phone” : “8931883”,
“account-no” : “1286-4499-0275”
}
PUT /user-profile?user=sam
{
“name” : “Sam”,
“phone” : “8931883”,
“account-no” : “1233-4655-0171”
}
200 OK

27. 6. Mass Assignment
27
● Mitigation
⦿ Don’t automatically bind incoming data and internal objects
⦿ Define all the expected parameters and payloads
⦿ Mark read only properties in object schemas
⦿ Define precise requests schemas and validate them at runtime

28. ● Improper configuration of the API servers allows attackers to exploit the
systems
7. Security Misconfigurations
28
Unsecured transport(HTTP)
Poor CORS policy enforcement
Unpatched systems
Verbose error messages

29. 7. Security Misconfigurations
29
● Mitigation
⦿ Continuous hardening and patching processes
⦿ System to locate configuration flaws
⦿ Include only required features
⦿ Restrict root access

30. ● Attacker makes API calls with syntaxes or commands that the API or backend
executee blindly
8. Injection
30
GET /accounts?id=' or '1'='1 "SELECT * FROM accounts
WHERE userId=' or '1'='1";
[ {“name” : “Sam”, “phone” : “78144753”, “credit” : 500000},
{“name” : “Mary”, “phone” : “43211234”, “credit” : 1000}]

31. 8. Injection
31
● Mitigation
⦿ Do not trust the client inputs
⦿ Do proper validation for input data against predefined schemas
⦿ Define, limit, and enforce API outputs to prevent data leaks

32. ● Attacker locates non-production or legacy versions of the API that are not well
protected, and uses to exploit the systems
9. Improper Assets Management
32
DEV
PROD
LEGACY STAGING

33. 9. Improper Assets Management
33
● Mitigation
⦿ Maintain an inventory APIs
⦿ Limit access to anything that should not be public
⦿ Separate production data from others
⦿ Have a proper API deprecation strategy

34. 10. Insufficient Logging and Monitoring
34
● Insufficient logging, monitoring, and alerting lets attackers to further exploit
the systems
Authorization: Basic <sam:pwd1>
GET /users/me
Authorization: Basic <sam:pwd2>
GET /users/me
Authorization: Basic <sam:pwd3>
GET /users/me

35. 10. Insufficient Logging and Monitoring
35
● Mitigation
⦿ Log anomalies in requests
⦿ Protect logs as sensitive information
⦿ Include information that can identify an attackers
⦿ No sensitive data in logs
⦿ Integrate with SIEMs and alerting systems

36. API Security with OAuth 2.0

37. One day you went for groceries and you parked your car near the store.
When you get back from the store, you noticed that someone has hit
your car...
At a glance you saw some paint scratches on your car...
So you took your car to the auto repair shop and handed over
the key...
Young Vin Diesel, one of the mechanics who works there saw your car & thought...
Let’s Start with a Story...
37

38. Perfect Opportunity for an
Ultimate Drift…!!!
38

39. Valet Key
Valet key concept is to have a special key which allows the driver to perform limited
functionalities under restrictions. So, when the valet key is used,
● Speed is limited
● Storage areas are locked
● Infotainment system is disabled
● Record the trip
39

40. The Password Anti Pattern
40

41. Access Delegation with OAuth 2.0
OAuth 2.0 was introduced in 2012 to solve this access delegation problem.
41
RFC6749 - OAuth2 Core
Authorization Code
Implicit
Password
Client Credentials
RFC6750 - Bearer Tokens
Request Header Field
Form-Encoded Body Parameter
URI Query Parameter

42. Authorization Code Grant Flow
42
User
Web Browser
Web App

43. Fast Forward to 2020...
43

44. What Changed in the API World
44
1st Party Apps
SPA

45. Over the past 8 years, we saw incidents which involve,
● Leakage of client (app) credentials
● Phishing
● Stolen authorization codes / access tokens
● Redirect URI interception
● Signature Verification Bypass
Things were not always perfect...
45

46. So we did lot to improve the security...
● RFC6749 Section 10
● RFC6819
● RFC8252 Section 8
● Security Best Current Practice - draft
46

47. Is it the time for OAuth 2.1?
47

48. Drafted OAuth 2.1
● OAuth 2.1 gets the best of OAuth 2.0(RFC 6749), Bearer Tokens(RFC 6750),
Native Apps (RFC 8252), PKCE (RFC7636), Browser Based Apps BCP(draft)
and Security BCP(draft)
● In Summary,
⦿ PKCE is required for all OAuth clients using the authorization code flow
⦿ Redirect URIs must be compared using exact string matching
⦿ The implicit grant (response_type=token) is omitted from this specification
⦿ The Resource Owner Password Credentials grant is omitted from this specification
⦿ Bearer token usage omits the use of bearer tokens in the query string of URIs
⦿ Refresh tokens for public clients must either be sender-constrained or one-time use
48

49. It is much simpler now...
49

50. Authorization Code Grant Flow with PKCE
50
Web App

51. 51
Roles in OAuth
Covered so far...
Now we look at...

52. Things to Consider for Protecting API Invocations
● Scopes & Resources
● Token Types & Validations
● Security Enforcement Point
52

53. Scopes & Resources
● Scope is a mechanism in OAuth 2.0 to limit the application's access to a user's
protected resource
● Sometimes scopes are overloaded to convey the location or identity of the
protected resource; however, doing so isn't always feasible or desirable
● Resource Indicators spec (RFC8707) is introduced for the application to
explicitly signal to the authorization server where it intends to redeem the
access token it is requesting
53

54. Token Types & Validations
● What type of token should be used?
⦿ Reference token
⦿ JWT
● How should we decide the validity period?
⦿ Based on user type
⦿ Based on operation type
● Is refresh token allowed?
54

55. Security Enforcement Point - API Gateway Pattern
55

56. Let’s Recap
56
● API security and security considerations
● Common API security vulnerabilities
● API security with OAuth 2.0
● What’s new in OAuth 2.1
● Things to consider when protecting API invocations

57. Question Time!
57

58. Next in the Series
58

59. wso2.com
Thanks!

60. References
60
● OWASP API Security Top 10 -
https://github.com/OWASP/API-Security/raw/master/2019/en/dist/owasp-api-security-to
p-10.pdf
● The OAuth 2.0 Authorization Framework - https://tools.ietf.org/html/rfc6749
● OAuth 2.0 Device Authorization Grant - https://tools.ietf.org/html/rfc8628
● OAuth 2.0 Threat Model and Security Considerations - https://tools.ietf.org/html/rfc6819
● The OAuth 2.0 Authorization Framework: Bearer Token Usage -
https://tools.ietf.org/html/rfc6750
● OAuth 2.0 Security Best Current Practice -
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16
● The OAuth 2.1 Authorization Framework -
https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00