Getting API security right - Philippe De Ryck - NDC London 2023
HTML-код
- Опубликовано: 26 сен 2024
- The shift towards an API landscape indicates a significant evolution in the way we build applications. The rise of JavaScript and mobile applications have sparked an explosion of easily-accessible REST APIs. But does the rise of APIs result in the downfall of security? Why are there so many vulnerabilities and incidents involving APIs? How can you ensure that your APIs are secure?
In this session, we use real-world cases to dive into best practices for securing your APIs. We discuss the attack surface of an API, common authorization problems, and best practice techniques to avoid these problems. At the end of this session, you will have an actionable set of guidelines to assess and improve the security of your own APIs.
Check out our new channel:
NDC Clips:
@ndcclips
Check out more of our featured speakers and talks at
ndcconferences...
ndclondon.com/
Excellent work here. Thank you. I am glad to see the focus on "Security First" instead of "Security as Technical Debt".
Very good! As a junior developer I had not thought these things through so thankyou!
Solid talk, great points. I really love the focus on Broken Object Level Authorisation, which is absolutely everywhere.
Even though I build Object Capability systems, which take care of many of these problems by construction, that point about WAFs is relevant to me, as DoS becomes a genuine risk when you have everything else covered.
I'm pretty proud to have come to the conclusion that OpenAPI is a useful tool for enforcing security between starting to play this and him suggesting exactly that.
Excellent talk. Auditability means you should be able to read the code easily
Great talk!
I was reluctant to watch this because security is boring. So glad I did.
I see many "Senior" developers who fail to understand these basic concepts even after hours of discussion.
00:00 Getting API security right - Philippe De Ryck - NDC London 2023
00:33 Knight Ink study, e-health apps
01:49 - Start taking security seriously
02:40 Self-introduction
04:24 - OWASP API Security Top 10
05:19 Bumble
06:30 Twitter
06:51 - The client is irrelevant for security
09:10 Grindr
10:46 - OWASP API Security Top 10, broken object property level authorization, excessive data exposure
16:47 - Test your APIs in their natural habitat
18:21 - API contracts
20:29 - Use Swagger/OpenAPI definitions for security
23:11 T-mobile, IDOR, insecure direct object references
25:08 REST API without authentication
27:31 - Enforce authorization at the function level
29:42 - Empower auditability
30:25 Object-level access control is often challenging to implement
34:06 - Centralize complex authorization logic
37:25 - Traditional web sessions are still valid
40:48 - Analyze your security requirements
42:32 - Follow JWT best current practices
42:51 What happens when things goes wrong?
43:27 - Compartmentalize your APIs
47:15 - Perimeter security requires a secure perimeter
I spent about 4 hours a week telling people people why windows integrated security requests won’t work with my azure Apim that’s secured by azure ad app reg.
👏👏👏👏👏
Surprised there is a 403 for something you are not authorized for.
I'd argue a 403 is only for something someone can know is there (so maybe a bad idea for other user records).
404 (deny it exists) is my strong preference if someone does not have access to an object.
There are transformations for that, but what happens if you have a valid user but they try update an object on which they only have read access? Should we 404 then?
First solution that comes to mind is to have the authorization policy return the error code to use; i.e. (C#) if (!AuthorizationPolicy.canDeleteTask(task, user, out status)) {return status}; else {/*...*/}. Very simple solution, and can do more complex handling like a 404 when the endpoint is hidden and a 403 when the operation is incorrect.
@@AlgoristHQHe did say "403 is only for something someone can know is there," so if they have read access but not write access, they know it's there, therefore 403 if they attempt to write it.
Little is more annoying than getting a 404 because your session expired or is insufficient. Just send a 403 for the whole tree beyond /my-secure-path/ whether the item itself exists or not.
Imagine an entrance where you have to present your batch card first. It's ok to know that access is restricted and way more obvious than a guard telling you that Mr Anderson doesn't work here until you present the proper token.
Also feels like abuse of the status codes and security by obscurity.
It SHOULD NOT be problem, if it is, you are doing "security through obscurity" for lack of a better term
34:33
API world !
it's not practical at all, too much talk and less code, 90% of this conference was talk with no sense, too much
Free courses on his site, how is that not practical
@@goldnutter412 too much talk, show me the code better
@@haroldpepete Guess you are working for T-Mobile?
@@haroldpepete, a general confrence with the information needed for you to learn the topics. Now you have what you need to go do the research and implement this is whatever code language you use.
This is what they are, about taking the anarchist to some sort of path to best practice.
Too much talk and self advertising 3/3
Free courses on his site
I wonder how many are using aspect-orientation for the centralization.