If you're only worrying about injection attacks "...after you gain some traction" or "...when it becomes an issue" you're already too late, and I don't ever want to trust any of my private data with you, ever. This is the 21st century. Scrubbing and validating user input is _trivial_ now, framework or no.
Please, please, please, everyone who reads this, spend a day reading the OWASP guidelines, and _use_ their sample code. This isn't difficult, and it makes your applications a million times more secure _on_ _day_ _one_.
This sort of behavior is why the rest of us get a bad rap.
http://blog.moertel.com/articles/2006/12/15/never-store-pass...
Needless to say, almost 5 years have passed and they're still around :) their traffic probably a couple of orders of magnitude higher. I was there when it happened, and yes, probably some Russian hacker or whatnot has my password from there, but that's not such a big deal because reddit doesn't know my name, doesn't have my CC number or any details related to my life.
Now, were this to happen to a company that has a lot more information available about each and every one of us stored in one central place (think Google or FB), then things could get really nasty. And I'm not talking about stupid mistakes like the one from above, I'm talking about MITM attacks orchestrated by (vicious) Governments, or cyber-warfare, or just plain old NSA not having to bother to collect information from a myriad of places anymore, when they can just go directly to the source.
I did not say you couldn't build web applications if you were a jerkass who was cavalier with the security of his users' data. I said you shouldn't.
That would have left us without reddit, I don't know about you, but without it the Internet would have been a lot less interesting.
First -- "the chances of that happening is very low." Let this be an education; there are automated toolsets that seek out and exploit known vulnerabilities in software across the entire Internet. If you have a public-facing website, you will get attacked. Period. The chances aren't "very low", they are a certainty. There are also toolsets that are used to do much more low-level scans for things like XSS, SQL injection, etc. These are commonly used by security auditors, but are also used by 13 year old kids who want to compromise your site. Again-- the chances aren't "very low", they are a certainty.
Next -- "...but the priority in any business to make profit first." State attorneys general are very quickly drafting personal privacy laws. I believe Massachusetts and Nevada are leading the way here, whereby any personally-identifiable information is _required_ _by_ _law_ to be held to the same rigorous data protection standards as PCI. If your site is breached, you will get sued, and you will lose.
Following OWASP takes maybe an extra day's worth of time out of a developer-- saying that you're just going to ignore it because hey, what's the worst that could happen -- again, I would ask you to list what you're building, so I can avoid it forever.
That said, one of the things that (hopefully) comes with experience is knowing when and where to cut corners. Basic security practices are one place where you need to bake your understanding into everything you do from a low level, because security is one of the hardest "features" to retrofit. Also because basic security does not have to be hard. Hell, you can make an informed decision not to use SSL on your login page, but it must be just that, informed.
Unlike the language du jour, security principles are something that will apply to all programming you do for the rest of your life. So, though you may decide not to use trendy framework x, y or z today, failing to learn basic security and apply it consistently will slowly turn you from a young developer with bright ideas and a lot of potential, to a middle-aged hack developer with a defensive chip on his shoulder.
1) upload scripts to send unsolicited email, getting your IP address banned.
2) upload scripts to scan the internet for other targets (most common---an SSH scanner)
3) modify the HTML output to leak Google Page Rank to questionable sites, which risks your Google Page Rank.
4) passwords of users, who typically use the same password on other sites.
5) setup an illegal file trading section, hidden from most users (anything from music and films to kiddie porn (saw this first hand, and what once was seen can never be unseen---shudder))
6) IRC clients to control botnets.
I've seen all of these first hand working at several web hosting companies. It's more than just "credit cards."
Stop doing it right now.
There are automated tools that detect injection vulnerabilities and people who will hack you for a dozen e-mail addresses and passwords (and, possibly, control of your server). Sanitizing user input is easy.
While I agree the odds of gaining lots of traction are small, when you do, it hits you very fast. You should at least know the hot spots of your application so you can optimize them easily when possible. I am not telling you to save user registration data on a Cassandra cluster just in case, but employing good algorithms when possible. My apps usually are able to generate JMeter config files that make load testing with real data very painless.