> If you can get away with it, outsource identity management to Facebook / GitHub / Twitter / etc. and just use an OAuth flow. OAuth isn't identity management, it's for authorization. Each of those platforms does provide it's own identity management, but that isn't OAuth.
I took that to mean use both identity management as well as OAuth.
I think the OP meant "hash them" with something like bcrypt.
Which raises the question: should you follow web application advice regarding security from someone who mistakenly uses the word "Encrypt" when they (actually or unintentially) mean "Hash?"
> Forms: When submitting a form, the user should receive some feedback on the submission. If submitting doesn't send the user to a different page, there should be a popup or alert of some sort that lets them know if the submission succeeded or failed.
I signed up for an Oracle MOOC the other day and got an obscure "ORA-XXXXX" error and had no idea if I should do anything or if my form submission worked. My suggestion would be to chaos monkey your forms because it seems that whatever can go wrong can. Make it so that even if there is an error the user is informed of what is going on and if there's something they can do about it.
One thing to note is login redirect. Please be sure that redirect parameter is local URI and don't redirect user to another site.
Maybe even append HMAC signature to that parameter with user IP and timestamp. Might be an overkill, but still be careful with craftable redirects, they might become vulnerability one day.
> If you can get away with it, outsource identity management to Facebook / GitHub / Twitter / etc. and just use an OAuth flow. OAuth isn't identity management, it's for authorization. Each of those platforms does provide it's own identity management, but that isn't OAuth.
I took that to mean use both identity management as well as OAuth.
1. Why use OAuth unless you want to grant 3rd parties access to your services data, on behalf of your customers?
2. Security best practices subject to "open for interpretation."
If you're new to web application development and security, don't blindly follow the advice of someone else who is also new to web application security. You should instead have a security audit with people who have experience in security, so they can help you identify where and why you're system is vulnerable. If no one exists on your team/company that does, then hire a consultant. Security is a hairy issue, and no si…
Security is never perfect. It is a deterrent, not impenetrable prevention. So sure, to security people, it is never good enough. To everyone else, a easy to digest blog post might give them food for thought that would make their work one step better than it was before, resulting in security that is still flawed, but better. So why not just accept the post for what it is - some basic advice to do that one better step.
"You don't have to develop for mobile..." ... well, no. Technically you don't have to. But you almost certainly should .
Was surprised to see this too, considering the article's title is Things to Know When Making a Web Application in 2015 If anything the advice should be inverted by replacing 'mobile' with 'desktop'
Yes, even moreso now since it hurts your Google page rank to not make your app mobile friendly.