Fred Wilson's 10 Golden Principles for Successful Web Apps
techvibes.com
techvibes.com
A lot of people don't understand that security holes in their applications aren't usually caused by a 0day in their framework, but instead sloppy security practices in the application itself. I break web applications for a living, and although I appreciate the consistent business, entrepreneurs and developers on Hacker News should understand that a critical hole will cripple their business.
Take some time before you let other people use your app (other than internal testing) and do a few simple checks:
- Am I sanitizing user-supplied input in my application? Can I throw a ' in a userid form, or will it break my SQL statements?
- If I put ''";<xss> in the search bar, and view source, are > and < symbols floating around the page?
- Am I relying on security through obscurity? This is a big one. "Oh, no one will find the hardcoded password in this world-readable configuration file six directories deep" is how infrasctructures get destroyed.
- Am I handling credit card data myself? Do I need to be PCI-DSS compliant?
These few questions will prevent 90% of XSS, SQL injection and CSRF attacks if you carry them out thoroughly. Don't realease a buggy webapp just to get hacked.
You are correct that the article (rightfully) provides a forumula to create a popular app. Sure, there are lots of technical details that weren't touched upon in this article, and certainly we are not going to enumerate each of them and criticize the author for not creating an end-all be-all make-the-best-app-ever article.
However, I do believe that security should be a primary concern from the very start. Think about security early, think about security often. Once your app is already popular with 500k active users is not a good time to realize your oversight in security, leading to a possibly fatal breach.
I'd welcome a counter-example: can you name a succesful startup that died because of lack of early security?
The way it seems to work today on the Web is succeed first, get the money, then fix whatever needs to be fixed.
I agree with you that being paranoid about security instead of working on a human-friendly interface, or worse--a functioning product--will absolutely hinder developments to grow, but that is not what I'm suggesting. In my experience, the vast majority of crippling bugs are simple things, that can easily be prevented using methods such as the four I listed. These should be part of everyday secure coding practices.
I would never tell a developer that they should stop working on their product to tinker with obscure security fantasies, but I'd also say that they're crazy if they don't include basic checks (such as ensuring on a basic level that user input is clean) as mentioned above.
Development methodologies like TDD include this inherently in the software life cycle: tests reaching outer bounds and unexpected input are regularly created to make sure that errors are handled correctly.
In the comments he mentions "it makes the app shareable on blogs, email, social media if every resource/page has its own URL". That's true, unless of course when 75% of your URLs are behind authentication, which is true with every paid app.
So the connection between sharing and REST doesn't make much sense.
Why not just say: make it easy to share? Or provide clean URLs for APIs?
The reason I think this is because the second half (of the two sentences) on the RESTful section says "...every resource on your site needs to have a URL and ones that people can understand". Additionally, there is another section for APIs called "programmable".
Seems like a minor misnomer, but still a good point.
Course technically it doesn't _have_ to be REST, but that's the buzz of the now.
People who have never used a diversity of web APIs (>= 20) should never be allowed to design them, or I will personally fly to their dungeons and strangle them with their own lousy documentation strings.
Test your "API" with a variety of languages, that are not C++ clones. If you can respond with a header value, don't make me parse a body (i.e. responding with 200 when the body says "error".) Accept whitespace liberally. Space should mean \\s+. Not just a particular " ".
Version your API. Don't obsolete stuff willy nilly. Even if you're clueless, it's not too hard to run three instances of the endpoint app, and route requests to a per-version instance with URL rewriting proxy.
Anybody who has ever sat in the specification committee of a "microformat" should never EVER be allowed near APIs that others might use. Specification-creep is real; one draft spec by 3-guys in their dorm room creeping into another spec by some other guys. I can cope with IETF and W3C pulling stuff out of thin air, but I will NOT tolerate being told to read several draft-0.01a.txt specs from 2003, for a myriad of "social identity" crap that no one, but those whose name appears on the first page, cares about.
Also, offer a sandbox, and dummy instances with mock data. Otherwise I will rape your live servers in a tight, unrolled loop (Srsly, I am on a fat pipe, running native x64 code; your instance of Jetty or WEBrick will never know what hit it.)
Can you tell I have been debugging?
And also, for the love of all that is holy, when you offer a sandbox and test data, give me a way to deliberately trigger error responses.
It's all well and good to give me an is_test parameter on your payment API, but if using it causes you to blindly approve all payments, I can't test all of the code paths dealing with all of the possible failure modes(true story).
Last client, travel biz, had APIs to many holiday and travel co's APIs. Some of the big ones, no names, had no mock data. Being travel data, live data changed by the second. Had to employ someone specifically to fix test data, and the tests, simply to allow the devs to work. Insane.
Corollary: The reason the travel industry is such as mess is its complete lack of understanding of, and refusal to engage with, its customers. It's really, really easy to fix, but the suits refuse to acknowledge the problems.
Regardless, useful points worth keeping in mind.