Download as PDF, PPTX
![● 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}]](https://image.slidesharecdn.com/apisecuritybestpracticesandguidelines-201026044050/85/API-Security-Best-Practices-and-Guidelines-30-320.jpg)
![● 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}]](https://image.slidesharecdn.com/apisecuritybestpracticesandguidelines-201026044050/75/API-Security-Best-Practices-and-Guidelines-30-2048.jpg)
Uploaded byWSO2
API Security Best Practices and Guidelines
The document outlines best practices for API security, highlighting the importance of addressing common vulnerabilities such as broken authentication, excessive data exposure, and insufficient logging. It discusses the role of OAuth 2.0 and introduces improvements proposed in OAuth 2.1 to enhance security in API access delegation. The presentation also emphasizes the need for continuous monitoring and proactive security measures to protect against emerging threats in the API economy.
In this document
Powered by AI
Overview of the API Security presentation and presenters, highlighting importance of security in API development.
Discussion of WSO2’s background, global presence, workforce, and key growth metrics including $49.9M ARR.
Introduction of WSO2 capabilities, especially Identity Server, focusing on identity management and API lifecycle.
Insights into the growing API economy, troubles faced, and the critical need for API security to prevent data breaches.
Identification of API audience types and access methods to emphasize the necessity of tailored security measures.
Introduction to the OWASP Top 10 vulnerabilities, a crucial framework for understanding API security risks.
Description and mitigation strategies for Broken Object Level Authorization, highlighting security check importance.
Explanation of Broken Authentication risks and recommended mitigation practices to enhance API security.
Discussion on the Excessive Data Exposure issue and best practices to restrict data output from APIs.
Addressing concerns around resource limitations in APIs and suggesting management strategies to prevent abuse.
Explanation of risks related to Function Level Authorization and the importance of sound access policies.
Identification of Mass Assignment vulnerabilities, emphasizing the need for careful input validation.
Explains risk factors in security configuration and best practices for hardening API security.
Description of Injection vulnerabilities and methods for ensuring that API inputs are adequately validated.
Discusses risks associated with improper assets management and strategies for maintaining API inventory.
Highlights the importance of logging and monitoring for API security and mitigations for potential issues.
Introduction to using OAuth 2.0 for securing API access and the concept of Access Delegation.
Summary of changes in API security landscape and improvements over the years since OAuth 2.0 introduction.
Overview of the new OAuth 2.1 draft, summarizing its major updates and simplifications from version 2.0.
Detailed discussion on the flow of OAuth 2.1, including scopes, token types, and enforcement points.
Wrap-up of the presentation, inviting questions, and directing attendees to resources and further reading.
Listing valuable references for further exploration of OAuth 2.0 practices and OWASP insights.
More Related Content
Similar to API Security Best Practices and Guidelines
![[Roundtable] Choreo - The AI-Native Internal Developer Platform as a Service](https://cdn.slidesharecdn.com/ss_thumbnails/choreo-deck-250328074645-511dded7-thumbnail.jpg?width=600ounds&width=560&fit=bounds)
![UiPath Automation Suite Installation (Hands-On) [2/3]](https://cdn.slidesharecdn.com/ss_thumbnails/automationsuitecommunitysession2-251015095633-a6d862f1-thumbnail.jpg?width=600ounds&width=560&fit=bounds)
API Security Best Practices and Guidelines
- 1. API Security BestPractices and Guidelines Thursday, October 22, 2020
- 2. Hello! Omindu Rathnaweera Thanuja Jayasinghe AssociateTechnical Lead thanuja@wso2.com omindu@wso2.com Technical Lead
- 3. About ‘API Securityand 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 APIlifecycle 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 Serveris 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 ● Identityfederation 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.
- 9. ● A substantialgrowth 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 becomethe #1 Attack vector by 2022 10
- 11. ● API accesscontrol 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 isthe 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 SecurityTop 10
- 15. OWASP API SecurityTop 10 15 ● Focuses on the top 10 most common vulnerabilities in API security
- 16. ● Attacker substitutesID 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 ObjectLevel 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 DataExposure 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 DataExposure 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 isnot geared to handle excessive amount of requests or payload sizes 4. Lack of Resources and Rate Limiting 22 . . .
- 23. 4. Lack ofResources 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 expectsclients 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 FunctionLevel 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 requestinput 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 configurationof 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 makesAPI 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 locatesnon-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 AssetsManagement 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 Loggingand 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 Loggingand 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 withOAuth 2.0
- 37. One day youwent 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 foran Ultimate Drift…!!! 38
- 39. Valet Key Valet keyconcept 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 AntiPattern 40
- 41. Access Delegation withOAuth 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 GrantFlow 42 User Web Browser Web App
- 43. Fast Forward to2020... 43
- 44. What Changed inthe API World 44 1st Party Apps SPA
- 45. Over the past8 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 didlot to improve the security... ● RFC6749 Section 10 ● RFC6819 ● RFC8252 Section 8 ● Security Best Current Practice - draft 46
- 47. Is it thetime 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 muchsimpler now... 49
- 50. Authorization Code GrantFlow with PKCE 50 Web App
- 51. 51 Roles in OAuth Coveredso far... Now we look at...
- 52. Things to Considerfor 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 ● APIsecurity 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.
- 58. Next in theSeries 58
- 59.
- 60. References 60 ● OWASP APISecurity 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