I'm about to launch my first web startup and am wondering how concerned I should be about abuse -- both from account holders and the public at large.<p>Background: our app is free to sign up and upload all of your content (URL is in my profile). The pay wall comes when you want all of that content to go live and be available to your users.<p>Example Concerns:
1. An account holder can upload unlimited content, but the common use case will only be what they have (on the order of 100MB most).
2. A user could feasibly switch their billing plan unlimited number of times.
3. The RESTful interface to the content requires no authentication and isn't throttled (it does do some header checking) and links to large media files are raw, source of request is unchecked on server end.
4. DDOS, general "script kiddie" stuff, dictionary attacks on root pw to servers (i use a non-standard port)<p>Everything that can be considered "harmful" would eventually be caught (woe be to my bandwidth bill) and dealt with, but possibly not before some "damage" has been done - namely a huge distraction and time sink to find and correct the issue/perpetrator.<p>How much "abuse" does your web app take?
How aggressive are you in preventing such behaviors?
The amount of effort you have to spend on this varies greatly with the attractiveness of your service to trolls, thieves, hoodlums, and the like. One of my apps has almost total trust for users, because exploiting the app itself gets nothing that someone on 4chan would enjoy. Another of my apps makes phone calls, and I put non-trivial effort into securing that from abuse.<p>You're in a content business. Bad news: technically inclined people enjoy stealing content. You probably have to plan on them using your service to facilitate theft of content unrelated to you. "Unlimited uploads" sounds like something that will draw this type of pathological user like flies to honey.<p>With regards to security: standard best practices are pretty adequate for most of us in non-regulated industries. I don't know why you'd let root be able to log in, but that is probably minor.
1. Very little.
2. Very little.<p>I've was the primary developer on an at-one-time popular site, and have been working at web startups for awhile. I don't recall a single malicious user on either (there were quite a few stupid users or users angry at me, but not messing with the site). Until you get big, people won't mess with you. Until you get big, you have little to lose if they randomly do mess with you. Writing robust secure apps is harder. Unless you deal with money or credit cards, just figure it out when it is actually a problem. (Protip: you will probably never be big enough for it to be a problem. I would spend all your effort figuring out how to get big, and then welcoming malicious users and script kiddies as one of the trimmings of success).
I've had spammers looking for open e-mail relays on a contact form on a personal site that gets one or two legitimate visits a month. Small sites can be an ideal target for spammers, as they're less likely to have time and money for intensive security analysis.<p>Just use common sense measures to avoid things like SQL, JavaScript, or HTML injection and external abuse (such as from spammers, pirates, or script kiddies looking for an untainted host for their malware), have a DMCA procedure in place in case a user does find a way to host illegal content on your site and you're in the USA, and deal with any other issues as they happen.
1) I would definitely implement a cap here - but something reasonably high... maybe 2GB is free, pay for more?<p>2) An app I wrote allowed this. We put a limit in that prevented more than 4 changes to occur within 10 minutes. If the user attempted a 5th change, they would get a message asking them to wait a few minutes.<p>3) Implementing a public/private key here is relatively trivial - any reason not to do it?<p>4) Hardware firewalls will help with a large portion of this. I had a server that would get brought to it's knees about twice a week from that fracking SQL worm. Added a hardware firewall instead of relying on the "non-standard" port and hard-to-remember password, and problem pretty much solved.<p>For applications that I write or control, I would put reasonable effort into "shaping" the worst possible abuses. For example, point #2 above - there's no real reason the user will ever change their plan more than a few times in a few minutes, so introduce a delay once a certain limit is reached. It won't cause any problems and will prevent confusion at the administration side.
When you are just starting -- there is no abuse, because nobody knows about you.
If you keep working on application and monitor it, you would be able to notice the abuse, fix it manually, and add features that would prevent it in the future.