In this presentation, we explain why OAuth and SSL are not enough when it comes to API Security, and that you should also think about addressing other aspects such as confidentiality, integrity, audit or compliance requirements. We expose the tactics to address each of those aspects, and a set of recommendations to apply immediately to your APIs development.

1. API SECURITY: THE FULL STORY

2. SPEAKERS
2
Philippe Leothaud
Chief Architect & CSO
Isabelle Mauny
CTO
How to reach us:
philippe.leothaud@42crunch.com
isabelle.mauny@42crunch.com

3. FIRST A BIT OF
VOCABULARY!
3

4. SECURITY HAS TWO DIFFERENT ASPECTS
➤Putting in place a security architecture achieving security
goals
➤Preventing from attacks against this security architecture.
4

5. SECURITY GOALS OVERVIEW
5
INTEGRITY Message has not been tampered with
CONFIDENTIALITY Message can only be seen by target audience
AVAILABILITY
Resistance to attacks, such as Denial-of-service
(DDOS)
AUTHENTICATION Identity of the caller is known.
AUTHORIZATION
We can guarantee the caller has proper
permissions to access a resource
AUDIT
System has non-perishable trace of all machine/
human actions.
NON-REPUDIATION
There is (legal) proof that the action has taken
place.

6. ATTACKS AND COUNTERMEASURES
6
ASSET
A resource of value such as the data in a
database or on the file system, or a system
resource (such as an API)
VULNERABILITY
A weakness or gap in security program that
can be exploited by threats to gain
unauthorised access to an asset.
THREAT
Anything that can exploit a vulnerability
and obtain, damage, or destroy an asset.
ATTACK/EXPLOIT An threat in action, to harm an asset.
COUNTERMEASURE
A safeguard that addresses a threat and
blocks attacks.

7. SECURITY IS A LAYERED APPROACH
7
APPLICATION SECURITY
Measures taken throughout the code's life-cycle to
prevent gaps in the security policy of an application, i.e.
flaws in the design, development, execution of an
application
SYSTEM SECURITY
Control of access to a computer system's resources,
specially its data and operating system files.
NETWORK SECURITY
Policies and practices adopted to prevent and monitor
un-authorized access, misuse, modification, or denial of
a computer network and network-accessible resources.

8. APPS INFRASTRUCTURE
EVOLUTION

9. API CENTRIC INFRASTRUCTURE
➤ HTTP (mainly), REST/JSON
and the ecosystem
➤ An application is a dynamic
orchestration of multiple API
calls
➤ Calls may be targeted to
➤ enterprise own APIs running internally
➤ enterprise own APIs running in the cloud
➤ external (public/partner/SaaS) APIs
running over Internet
9
Internal Applications Legacy Systems
Application
Server
Databases
Integration
Layer (ESB)
App1
Services &
MicroServices
SaaS ApplicationsThings
APIs

10. THE WORLD AS WE KNEW IT
➤ Established Perimetric
Defense
➤ Defense in-depth
➤ Limited set of client types
➤ Limited number of entry
points for apps
➤ Slow delivery of apps
10

11. TODAY
➤ No more clear security perimeter
➤ Multiplication of endpoints,
internally and externally
➤ Multiplication of protocols
➤ Uncontrolled client types, typically
devices, which may have been
compromised
➤ Fast delivery of apps, some
shortcuts are taken
➤ Microservices architectures are
multiplying the set of OS/
frameworks to secure and manage.
➤ Cost of explosion of C in MVC
(Controller)
11

12. SECURING A SINGLE API
12

13. API ECOSYSTEM STATE OF THE ART
13
GOAL TACTIC STANDARDS
INTEGRITY/
CONFIDENTIALITY(Transport)
Encryption/Signature TLS
INTEGRITY(Message) Digital Signatures JWS
CONFIDENTIALITY
(Message)
Encryption JWE
AVAILABILITY Rate Limiting/Throttling
No standard - Must be part of API
Management solution
AUTHENTICATION Identity Management
OpenID Connect
OAuth2 Authentication flows
AUTHORIZATION Fine-grained permissions model OAuth2 + ????
AUDIT
Write transactions to permanent storage
(encrypted/signed/protected)
No standard - Must be part of API
Management solution
NON-REPUDIATION
Write transactions to permanent storage
(encrypted/signed/protected)
No standard - Must be part of API
Management solution

14. A WORD ABOUT OAUTH…
➤OAuth was created to solve a specific problem: allow a
resource owner to give access rights to their personal data to
an application.
➤However, whenever the need to control the access to enterprise
data, OAuth may not be enough, or may not scale.
➤Need to introduce fine-grained authorization, based on
information on the resource consumer.
• Engage XACML engine to take decision
• Pass JWT token to back-end so that it can take a decision.
14

15. SECURING
APPLICATIONS
15

16. Madrid App
Internal
APIs
Stripe
Payments API
Starbucks API
GoogleMaps API
ORCHESTRATION AT APP LEVEL
➤ Who manages credentials for
SaaS apps ?
➤ Where are those credentials
stored ?
➤ Where do we control the
application flow of the APIs?
➤ Security (in particular of data
at rest) is handled at app level
➤ Complexity
➤ Deployment Agility
16

17. ALTERNATIVE APPROACH
17
Enterprise Border
Stripe
Payments
Starbucks
GoogleMaps
APIsFirewall
APIMediation

18. SEC DEVOPS

19. SECURITY TESTING IS FULLY PART OF DEVOPS
➤API-led architectures are bringing unparalleled agility to
enterprises, with the ability to leverage business logic exposed
internally and externally, coupled with a scalable architecture.
➤A study shows that applications will likely need to be released
around 30 times per year in order to keep up with innovation
driven by customer demand. This is close to impossible
without continuous development and continuous testing.
➤Security must not be an afterthought, but rather something
you continuously consider in the development and deployment
cycles.
19
If security slows down innovation, it will be bypassed.
If security slows down innovation it will be bypassed!

20. RECOMMENDATIONS
20

21. TARGET API INFRASTRUCTURE ARCHITECTURE
21
Application
Server
Databases
Integration
Layer (ESB)
App1
Services &
MicroServices
SaaS ApplicationsThings
Security Policies
Web Apps and APIs Firewall
Security Policies
API Security Policies

22. ENFORCE THIS COMPREHENSIVE API SECURITY POLICY
1.White-listing enforcement: URLs + queryString parameters + HTTP Verbs + HTTP headers control CORS, X-Frame-
Options, Strict-Transport-Security header (HSTS), etc.
2.Anti-DOS protection (technical quotas)
3.Replay attacks protection(using a nounce)
4.Check maximum input message size
5.Decrypt eventually
6.Verify signatures if any
7.Check JSON/XML payload to protect parser (size, complexity, depth, etc.)
8.Validate/sanitize input JSON/XML using schema
9.Check for applicative attacks (SQL Injection, XSS, CSRF, Clickjacking etc)
10.Authentication
11.Authorization
12.Enforce application flow and session handling
13.Validate/sanitize output JSON/XML using schema
14.Check maximum output message size
15.(Optional) Sign output message
16.(Optional) Encrypt message or parts of message)
17.Control outgoing headers (mainly CORS headers).
22

23. SUMMARY THOUGHTS
➤While OAuth and OpenID connect are important, they are
clearly not enough
• Need to take holistic approach including reaching all security goals
➤Complement OAuth with a fine-grained, enterprise level
authorization model
➤Comprehensive security
➤Application security starts at development time (SecDevOps)
➤Favor deploying API orchestrations on the server side in order
to enforce security and proper order of API calls.
• Even when deployed on the client side, enforce application flow control on
server side.
23

24. REFERENCES
➤Defense in-depth
• http://searchsecurity.techtarget.com/definition/defense-in-depth
➤OWASP REST Security Cheat Sheet
• https://www.owasp.org/index.php/REST_Security_Cheat_Sheet
➤Transport Layer Security Cheat Sheet
• https://www.owasp.org/index.php/HTTP_Strict_Transport_Security_Cheat_Sheet
• https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet
➤HTML5 Security Cheat Sheet
• https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Local_Storage
24