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.
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.
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.
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.
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.
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.
[0]: https://news.ycombinator.com/item?id=9369642
[1]: http://en.wikipedia.org/wiki/Non-functional_requirement
I feel somehow though that the line between functional and non-functional requirements are not as well defined when dealing with user data. There is an expectation (even if unrealistic) that the confidentiality, availability, and integrity of the user data will be preserved. Twitter though can serve as a counterpoint to part of this argument (availability).
Are there examples of a successful MVPs that dealt with user data and failed the confidentiality or integrity requirements?
I think there are many examples of successful products that had and/or have security issues. Think of all those apps that transfered user data over insecure connections.
The problem with those non-functional requirements is, that they are not all equally important and their importance varies from product to product. They are often ill-defined and hard to fully formalize. Nevertheless I think there are obvious "industry standards" (Update your stuff, encrypt at least connections).
Programmers and managers are people and mistakes happen, but just ignoring security altogether is negligent and one should be held accountable in the case of damages. Stuff like Sonys ten year old Apache getting hacked simply must not happen.
The federal privacy laws in Germany are quite good in that area [0]. It is explained well how you have to handle other people's data:
Where personal data are processed or used automatically, the internal
organization of authorities or enterprises is to be arranged in such a
way that it meets the specific requirements of data protection. In
particular, measures suited to the type of personal data or data
categories to be protected shall be taken,
1. to prevent unauthorized persons from gaining access to data
processing systems with which personal data are processed or used
(access control),
2. to prevent data processing systems from being used without
authorization (access control),
3. to ensure that persons entitled to use a data processing system
have access only to the data to which they have a right of access, and
that personal data cannot be read, copied, modified or removed without
authorization in the course of processing or use and after storage
(access control),
4. to ensure that personal data cannot be read, copied, modified or
removed without authorization during electronic transmission or
transport, and that it is possible to check and establish to which
bodies the transfer of personal data by means of data transmission
facilities is envisaged (transmission control),
5. to ensure that it is possible to check and establish whether and by
whom personal data have been input into data processing systems,
modified or removed (input control),
6. to ensure that, in the case of commissioned processing of personal
data, the data are processed strictly in accordance with the
instructions of the principal (job control),
7. to ensure that personal data are protected from accidental
destruction or loss (availability control),
8. to ensure that data collected for different purposes can be
processed separately.
One measure in accordance with the second sentence Nos. 2 to 4 is in
particular the use of the latest encryption procedures.
Such offenses shall be prosecuted only if a complaint is filed.
Complaints may be filed by the data subject, the Federal Commissioner
for Data Protection and Freedom of Information and the supervisory
authority.
[0]: http://www.gesetze-im-internet.de/englisch_bdsg/englisch_bds...
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.
If someone might just game the site and get something that wont affect anyone else, then you might ignore the fix for a while.
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.
Huge difference between terribly stupid and realistically aware of pros and cons.
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.