We want to provide value to users. We never want to put them in a worse place than they were when they came to us. Preventative security measures largely protect from these scenarios. But as with any other priority of the company, these concerns can be analyzed with numbers and approached with a rational risk assessment. The purpose of security measures is to properly manage risk with a reasonable cost benefit analysis to protect user integrity, data, and privacy.
Common Attack Vectors
A vector is defined as a attack strategy. Here are the most common security risks facing early companies: User impersonation or IAM (identity and access management) issues - protecting fidelity of user logins and not allowing unauthenticated or unauthorized individuals access. Authentication is the process of identifying who is trying to access. Authorization is the process of confirming that individual has proper access. This attack vector is addressed with password protections, locking down the app to non users, protecting from account hijacking.
Misconfiguration - ensuring all libraries and tools are using a stable and secure version and play well with the others. Some languages and tools have day 0 security bugs. Day 0 refers to when a bug gets exposed or exploited. Day 0 is before it is released, basically "this version was shipped with a bug". APIs like Synk analyze libraries with a framework (in this case JavaScript) to help stay away from bad versions or incompatibilities.
Database isolation - keeping pid (personally identifiable data) or sensitive data walled off and isolated from the public internet. No access should be exposed to anyone unauthorized, and employee access should be tracked and tightly controlled. This is where a lot of large company leaks have happened, letting this get exposed. A common tactic here is to lock your database instance to a whitelisted set of IP addresses, not open to the public internet for constant password testing and hacking.
Retention - routinely deleting sensitive information that is no longer immediately necessary or in use. This can mitigate damage for other failures.
Other security concerns - potential issues without a malicious actor
Data loss - maintaining proper backups. A backup that is not routine restored and checked, is not a backup. Hardware these days is almost universally considered "commodity hardware", which means it is cheap and designed for failure. It is planned to fail, and you need to write your software with this plan in mind, namely with redundancy.
Regulatory compliance - ensuring you comply with all policies and laws, and do what you can to ensure data is not accessible to authorities. This may be related to retention, where you delete unnecessary data so you physically cannot provide certain data when subpoenaed.
Data location - a relative of compliance, some data needs to live in specific physical locations. Be aware of these requirements and comply.
Tradeoffs and cost analysis
For early companies, you want to build on a strong foundation, do what is robust and reasonable. But do not obsess over every security eventuality. You need to be nimble and settle into a clear and profitable market need. To do this, you can't have extra thousands of lines of security code, or persnickety compliance officers making sure everything is perfect. Finding market fit is a fast and agile process. Do this first and worry further about protecting something valuable when you get something valuable that needs protecting. A data breach with 10 users on an app that isn't valuable won't close your doors. Not building something that can find thousands of paying customers will close your doors.
If you want a security audit of your MVP, or think MVP Engineer can be a strong partner for your needs, reach out.