I'm in a situation in which I have to decide between security of the application and shipping fast. The idea that we're working is not yet evaluated but we believe it has the potential to go viral. What would be the ideal thing to do here, build the product perfectly or to ship fast and fix later?
There's no reason for security to slow you down when building version one of a product.<p>Application-level stuff like enforcing that User A can't modify User B's data takes no time to implement, and should flow out into the IDE as fast as the actual code for the feature if you keep it in the front of your mind. It just wouldn't feel right to write the IF block that checks whether a record exists without also checking that its userID matches up with the current logged in user.<p>Similarly, database constraints all go in at design time. The schema isn't ready until bad data won't fit. No extra time needed there either.<p>Beyond that, you're into stack and infrastructure security stuff. Pick your platform well and you get most of it for free. Good luck trying to author a SQL Injection bug in a compiled language with parameterized queries, for instance.<p>Really, it's all about having built things in the past, knowing what sort of issues need worrying about, and getting into a habit of never half-assing things. If you do that, you have to go out of your way to mess things up. It'll feel so wrong to cut corners that it'll probably actually slow you down to do so.
What will you do if/when it's in the hands of 100K users, you are working as hard as you can to keep up with bug reports, and some 14 year old figures how to exploit a security hole to do something that will make <i>everyone</i> angry with you?<p>Security is really, really hard to back-patch - some would say impossible. If it's not there at the beginning then you will either never have it, or you will have to do a complete re-write.
MVP stands for minimum <i>viable</i> product. It really is about focusing on the features users need the most. It is not about shipping crap. Eric Ries has stated just two weeks ago on HN [0], that this is a common misunderstanding.<p>Security is a non-functional requirement [1], not a feature. It is not something you can prioritize on or not. Fortunately getting the basics right on the application level is not that hard, there are already many useful tips in this thread.<p>[0]: <a href="https://news.ycombinator.com/item?id=9369642" rel="nofollow">https://news.ycombinator.com/item?id=9369642</a><p>[1]: <a href="http://en.wikipedia.org/wiki/Non-functional_requirement" rel="nofollow">http://en.wikipedia.org/wiki/Non-functional_requirement</a>
Security is a stance not a feature. Being caught vulnerable and on the back-foot can be /really/ hard to recover from.
Do risk-based security, and be realistic about remote risks.
It sounds like there are already concerns about identified risks.
Well it all comes down to what bug holes you will release and what type of data you will be handling.<p>If you will be handling sensitive people information then you need to make sure that those are safe. Last thing you want is you new startup to be easily exposed and get a beating.<p>If someone might just game the site and get something that wont affect anyone else, then you might ignore the fix for a while.<p>But you should try and build whatever you are with a relative safety net. You cannot have bugs and holes in your system that will expose the system to hackers that will take over everything. Cause then it will be game over for you. No one will trust you afterwards.
You can simply do the best to merely record what's going on (ship your logs off to a system that's super well secure and basically write-only with minimal services as fiat). Additionally, somehow protect data sufficiently well that the problem would not cause catastrophic loss of data. A start-up went under after attackers managed to get their AWS access keys and wiped out everything in all their accounts after refusing to pay the ransom fee.<p>Huge difference between terribly stupid and realistically aware of pros and cons.
It's a balance. To paraphrase Steve Yegge: if you dial up security to 100 and accessibility (or in your case, working MVP) to 0, you die. If you dial up working to 100 and security to 0, you can win.<p>If you have no idea if this MVP has any promise, I'd seek the answer to that and do the barest of minimum security, provided you'll have the willingness to do it right immediately after getting any traction. That can be easy to say and hard to do, of course.
Frameworks will give you security best-practices and a faster shipping time. Of course, frameworks aren't bulletproof; but if your understanding of security isn't up-to-date then a framework will provide you some shielding against SQL injection, CSRF, etcetera – and will almost certainly help you ship a product faster since you will reduce the amount of boilerplate you're writing.
With all due respect, doesn't everyone think their product might go viral? It probably won't. You'll have time to fix the security after you launch.