I worked for a startup and found cross site scripting vulnerabilities and other issues like GET urls for deleting things. I was told to leave it alone and not "waste my time" because we dont have a lot of users and we weren't popular. I cringe at the justification. Security should be a necessary skill. It shouldnt be something after the fact
I call this the "we don't do anything special" fallacy. They consider hackers to be something like in the movies where a team of slick black leather clad folks plan a digital heist, and why should a bunch of movie stars care about our little business.
In truth it's much much more like how Google just has computers trying to index every site on the internet that they can find. Most of the attacks these days are broad searching things, just testing every exploit they can against every site they can.
Also, seriously, Google will find and index those GET+DELETE non idempotent URLs and ruin their day.
Absolutely true! I have to tell people that many attacks just try every door to see if its unlocked. They are not movie plot-style targeted attacks. And such an attack can and do lead to data breaches!
This is why I absolutely believe and publicly talk about security being a matter of developer ethics. I have used my walk away power to get a company to do the security they needed in a similar, but not quite the same type of situation.
I think they were right to tell you to leave them alone, but a better answer would be: "we'll add them to our backlog (or whatever way you manage issues or work), and get to them by X iteration". As long as you were really working on an MVP and not a version 1.x .
That's technical debt, and it's hard to fix. A prototype, sure, it can have flaws, it's a proof of concept of feature X, not feature X SECURED. But then the release has to be a rewrite. If it's not, those flaws are more likely to become permanent. And when they do begin work on repairing their codebase, they'll spend several times the money and time to fix than if they'd spent some time early on. They'll also likely introduce numerous other issues in the process.
Ok, I'll clarify: I think they were right as long as it was a throwaway prototype. And the GET delete operations are probably a bad idea even for a prototype. I was thinking of a rewrite for release 1.x.
I don't have enough knowledge of the stage the OP's startup was to have answered, so I stand corrected.
These days, this is the kind of thing I negotiate up front. When they ask me how long something will take, I explain that they can have a prototype quickly, but only if they promise to throw it away as soon as the experiment is done. I explain that they can have me build a movie set or a real house, but that there's nothing in between. [1] And then I leave the choice up to them, explaining that it's really about their business judgement.
Generally people keep their promises on this, although sometimes it takes a little reminding. When they do, the business benefits are substantial. A good product person really benefits from doing quick, cheap experiments. And they also benefit from having a solid platform of high-reliability code for production use. But they can only get the benefits of both if they're careful not to mix the two.
I'm old and have been in this industry a long time, and I'm genuinely surprised on those oh-so-rare occasions when what you describe doesn't happen.
Prototypes-become-products is a trope much like _The Mythical Man Month_. We all nod knowingly when it is mentioned, we all know how it will turn out, and then we (well, management dictates that we...) turn right around and do the opposite.
The problem is those things end up being forgotten or interfaced to in so many places that in the end they become un-fixable or won't be fixed to keep other stuff running.
I was thinking more of a throwaway prototype, but the answers on other threads convinced me it wasn't good advice, and I don't know what stage the OP's startup is.
