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
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.
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.
@@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.
![Seungmin "그렇게, 천천히, 우리(As we are)" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/kAzmhLHePqU/mqdefault.jpg)
Excellent work here. Thank you. I am glad to see the focus on "Security First" instead of "Security as Technical Debt".
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
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
I wonder how many are using aspect-orientation for the centralization.
Great talk!
I see many "Senior" developers who fail to understand these basic concepts even after hours of discussion.
I was reluctant to watch this because security is boring. So glad I did.
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
API world !
34:33
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