Common API Security Pitfalls - Philippe De Ryck

[@teeesen]

Great talk. A small quibble: At 18:20, we know we can trust the token because it’s defined on line 1. There’s no point to verifying it at run time, when you can verify it at design time. The quiz might be more effective if it weren’t clear that the token doesn’t come from a client. I know I’m taking the code too literally, but if you show someone code and ask them to find a security problem (or any other kind or problem) they should be reading with a very literal mind set.

[@gwaptiva]

It's when external consultants tell your management "Oh, yeah, easy to convert that to a REST API" and you spend the next 2 years having to explain to your manager that "yes, it's easy to make a REST API, but not so easy to make sure that that REST API doesn't dump our customers' data all over the internet"

[@jbird4478]

Good to see the Javascript world finally rediscovered public-private key infrastructure.

[@seizepartproduction]

at 22:36, is the proposed "JTI" solution optimized? Because fetching invalid tokens in a ( huge ) database, might be long ?

[@arendsmit3617]

31:53 How is providing an additional key in any way a valid behaviour here? The party verifying the token will only need a x509 certificate. Only if the "with a key" part is not contributing extra information but was meant to explain that the certificate intrinsically contains a/the public key it has some value. It probably should be changed to "..certificate which contains the public key"

[@ozzyfromspace]

This expanded my considerations for API architecture quite a bit. Thank you Philippe, you rock! 🎊🏆

[@seancpp]

It’s one of my biggest gripes with modern software learning material: pretending security doesn’t exist. It’s always a side note like “that’s a topic for another discussion” I think maybe because security is not a proven thing, and large relatively secure companies are hacked all the time. It makes it more similar I think to giving financial advice. Usually people hesitate, and if they do they provide a disclaimer. How can an indie application developer possibly learn security without becoming an infosec expert?

[@PierreThierryKPH]

I think it's bad advice to encourage systems to CHECK permissions. This opens a vulnerability to a confused deputy attack at the least. Better yet to make it impossible to make it unauthorized requests.

[@johnniefujita]

some of the best world's best news companies, such as; "the economist" suffer from that overexposing the contet! they send it to the client to block it afterwards... instead of sending just a preview! I already sent them a vulnerability report, but they don't really care apparently

[@kehaarable]

because it's just content -- the number of people doing this is likely small, and the type of people doing it likely won't pay anyway.

[@jbird4478]

They have reasons for that actually. a) The people who circumvent this paywall are not likely to pay anyway. In fact, the hassle of circumventing this every time makes it more likely they'll eventually just subscribe. If you simply ban them from any access, they won't even ever come back. b) To prevent those same people from setting up other ways to share it illegally. Now, if you search for how to get passed the paywall, you'll find articles explaining the steps you need to take. What you don't find is illegal sites simply rehosting the same content, but that's what people would turn to otherwise.

[@khatuntsovmikhail6223]

``` 12 hours running token``` seriously? I think it is not `tocken` problem.

[@gregyeo110]

Some client requires it because there are offline situations. But the situation might be sure to store the token securely. If we only focuses on Web Security, your reaction is.