Shipping Faster vs Security
I got a lot of insightful answers to my post "It's taking me a year to launch. Am I doing everything wrong?"
A lot of people suggested cutting out way more than I expected.
However, I was really surprised that people repeatedly suggested leaving out security measures like CSRF prevention and backend validations.
I'm no security expert. So I feel even more vulnerable because I don't know what I don't know.
I don't know what's possible for hackers to do with my app- If they got hold of the backend data, could they use my users stripe account id to take their money? Could they find the real identities of my customers from their email or their stripe account ID (something my potential users would not like as most use fake identities online). I would feel terrible if I betrayed my users by exposing their information.
Some of my software engineer friends were mortified when I told them that people suggested launching before I implement security measures. "Why would you open yourself up to an attack just to launch faster?" To make matters slightly worse, I am participating in #BuildInPublic- my whole code base is open. So people could find my security vulnerabilities.
But some indie hackers on here made a point- who is going to put in the time to hack a very small new app? This made sense to me. But the extreme reaction of my software engineer friends gave me pause.
Are my software engineer friends evaluating this risk incorrectly? Or are indie hackers giving me general information that might not apply to my nuanced application which might have more risk?
Any advice on how to navigate this concern?
Original Post: https://www.indiehackers.com/post/its-taking-me-a-year-to-launch-am-i-doing-everything-wrong-89b77ed26c
UPDATE 6/27/21_
Here's what I decided:
I went through the most common OWASP 10 security vulnerabilities. I also found some videos/tutorials on security vulnerabilities of the tech stacks I'm using and how the top OWASP vulnerabilities look like in that stack, to get more of a concrete example. I didn't need to go through all 10 because some didn't apply at all.
I then thought through which of those attacks would be permanently damaging and which would be annoying but reversible.
For example, my users need to keep their identities private. So I do not want any attacks that could expose their identities. Hence, measures to prevent these attacks are a priority. If my user's identities are exposed that puts them in danger, and there is no fixing it nor my reputation.
However, other attacks may only be annoying, but reversible. A DOS attack would be annoying, but it wouldn't cost anyone permanent damage. Once fixed, everything is back to normal. Conversely, an app that runs some emergency system and needs to run 24/7 could have permanent damage done from a DOS attack. So evaluating the risks is going to be based on the specifics of your app.
You need to ask yourself:
- Which attacks are reversible and which are permanent?
- Which attacks would hackers be most motivated to commit?
Please don't skip security.
Sure, take some shortcuts, but not in terms of security.
Try to find some other shortcuts: use templates instead of doing your own frontend from scratch, don't refactor your code all the time, ship without all the features you planned, ...
But security should always be something to keep in mind.
Imagine a carnival attraction, would you rather have a more boring safe attraction or an exiting attraction that could hurt someone?
(Commenting on this as well since you asked me to!)
I wouldn't say that you should "leave out" these things. It makes it sound like you're consciously choosing to write the code in a more vulnerable way.
If you're looking for a checklist, I'd start with the OWASP Top 10:
https://www.hacksplaining.com/owasp
Basically, try to hack your own app using any of these 10 strategies. If you don't find vulnerabilities (and you've handled encryption through HTTPS and an encrypted database) then you should be good for launch.
No, they could not. To leverage the Stripe API, you need a Stripe Secret API Key, which hopefully is being kept as a secret on the server-side of your project (and also not being tracked in Git!). Without this, even if they make the correct API call to return a customer's billing information, Stripe will return the HTTP status code 403 - Forbidden.
Here's from Stripe:
Video here
Overall, I think an important thing to keep in mind is that bringing in vendors (such as Stripe) will almost always be better from a security perspective than trying to implement it yourself, especially as a relatively new programmer. Stripe spends millions on security of their product, and I'd always rather trust my payment details to Stripe then to some random developer.
Many languages and frameworks also handle some of this workload for you, either explicitly or implicitly. I don't know your tech stack, but it would be worth doing some research as to what the framework your using protects against by default.
Hope that helps!
Thanks so much for you pov and the resources. will check them out.
Security isn’t as opaque, difficult, and mysterious as people think. If you’re building a web app, pick up a copy of The Web Application Hacker’s Handbook. Read through it, and you’ll know what you don’t know :)
Thanks for the book rec!
Skipping CSRF sounds pretty bad to me!
I don't have a solid answer - everything is a trade-off for sure! And you are definitely in a unique position. I'd try collecting my thoughts - make a list of scenarios, guess at how likely they are and what damage it could cause, and start there to decide what to do.
Example:
How could they use my app to get what they want? Exploits, loopholes, etc.
What would happen if they got access?
How likely is this scenario?
Mitigation options: ...
Maybe you have options to anonymize user data somehow, encrypt it, etc. You can also send a stripe support request - they were really helpful to me when I used them for the first time a couple years ago!
Thanks Andrew! Do you mean encrypting in my database? I understand pw encryption because I never need to see it. But an email- my app would need to know to send emails, so I don't understand that. Or are you talking about something else? Stripes Data?
There are some crazy encryption strategies you can use to reduce risk. Like e2ee, and encrypting emails and secure user data that only a special server can decrypt and work with. And just a note: RSA (pretty much the original 2 factor hardware key provider) did this, and they still got hacked!
But I'm causing a loop in your original question - I still can't answer "how much time should I spend on security?" :-P
For email, for example, maybe your target audience is used to having multiple accounts, and you can recommend they use a burner email instead of their primary?
And for Stripe data, it's similar. If someone finds your stripe key (or is able to execute code that uses it), they'll have access to everything that key has access to. I've thought about this, and my answer for my app was "it's not good, but they can't use it to give themselves money, so I'm ok."