Not trusting user input is a good start, but the client shouldn't be trusted, either.<p>I have seen plenty of web apps that fell short on this...<p>Whenever I'm on a web app that has a button shown but disabled, you can be pretty sure that I will enable that button and click it...<p>If the client is limiting the maximum length of the contents of a textbox, I'm probably going to change that and see if the server is performing the same validation...<p>My favorite so far, though, was client-side calculation and validation of order amounts for some products. Intercepting the JavaScript file and tweaking it before the browser started using it allowed me to place an older for a bunch of products for only $0.01 (going negative was also attempted, too, but this particular system did a pre-approval with a payment gateway and it didn't like that... so I settled on a penny).<p>These were all things I've done with permission, of course... but it's amazing what you can do when people assume the browser will always follow the rules...
These types of guides always overlook the most important principle of software security:<p>Always avoid reading, storing, or interacting with secure, personal, or otherwise "interesting" data. As much as possible, strip this information from your application, so that <i>when</i> it gets pwned the blast radius is absolutely miniscule.<p>Create software not liabilities.
Wow did I miss arguably the most important box to check, KISS?<p>Seriously, keep it EFFING SIMPLE. The more complex and involved it is the more things can and will break.<p>Does no one follow that anymore?
Can anyone explain what this means (or point me to somewhere where I can learn?)<p>> If a stateless architecture being used, use a MAC or an authenticated encryption mode to authenticate input.<p>I ask as a developer of a SaaS product. I understood most of the tips but not this one.
This security list is only a partial list, and it's not realistic for a busy programmer to cover everything well.<p>On the other hand, visual tools(low-code/no-code), sold in cloud based models(and probably grabbing a lot of money), are backed by teams of experts who do security well and don't expect the user to do any of it.<p>And as for tools take 100% of the security burden from the hands of the programmer - i haven't seen any.<p>So my conclusion is: where security will matter - visual tools will dominate.
Great guide. Reminded me of some of the learnings from the Pokémon Go hacking expeditions I wrote about last year (<a href="https://medium.com/@salqadri/a-peek-into-the-pokémon-go-hacking-scene-68d219134b14" rel="nofollow">https://medium.com/@salqadri/a-peek-into-the-pokémon-go-hack...</a>).
>Ensure use of Anti-CSRF tokens, CORS, and crossdomain.xml policies to prevent an attacker from forcing a user to submit authenticated requests.<p>isn't crossdomain.xml an adobe flash thing?