Getting API security right - Philippe De Ryck - NDC London 2023

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/

[@EldonElledge]

Excellent work here. Thank you. I am glad to see the focus on "Security First" instead of "Security as Technical Debt".

[@JulianneCohen]

Very good! As a junior developer I had not thought these things through so thankyou!

[@zombie_pigdragon]

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.

[@capability-snob]

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.

[@wildpett]

Excellent talk. Auditability means you should be able to read the code easily

[@maxbarbul]

Great talk!

[@sidekick3rida]

I was reluctant to watch this because security is boring. So glad I did.

[@ticler]

I see many "Senior" developers who fail to understand these basic concepts even after hours of discussion.

[@kbrnsr]

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

[@coderider3022]

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.

[@myspexg]

👏👏👏👏👏

[@goldnutter412]

API world !

[@sinamobasheri]

34:33

[@LewisCowles]

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.

[@AlgoristHQ]

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?

[@zombie_pigdragon]

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.

[@Tony_Goat]

​@@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.

[@karoshi2]

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.

[@sinamobasheri]

It SHOULD NOT be problem, if it is, you are doing "security through obscurity" for lack of a better term

[@haroldpepete]

it's not practical at all, too much talk and less code, 90% of this conference was talk with no sense, too much

[@goldnutter412]

Free courses on his site, how is that not practical

[@haroldpepete]

@@goldnutter412 too much talk, show me the code better

[@KD2139-b]

@@haroldpepete Guess you are working for T-Mobile?

[@EldonElledge]

@@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.

[@coderider3022]

This is what they are, about taking the anarchist to some sort of path to best practice.

[@bananasba]

Too much talk and self advertising 3/3

[@goldnutter412]

Free courses on his site

[@nyrtzi]

I wonder how many are using aspect-orientation for the centralization.