"The rules are, while quite reasonable, not entirely trivial. In order to work on a Ruby on Rails app, you just have to know them. As the app grows, it depends on more and more of these almost-trivial bits of external knowledge. Eventually, the sum of all the almost-trivial bits is decidedly not trivial. It's a whole ecosphere of things you have to learn to work on the app and remember while you are debugging it," he says.
To make matters worse, the frameworks can often leave you, and any who come after you, stranded with pretty code that's difficult to understand, revise, or extend.
As Mike Morton, another programmer, explains, "They carry you 90 percent of the way up the mountain in a sedan chair, but that's all. If you want to do the last 10 percent, you'll need to have thought ahead and brought oxygen and pitons."
Programming mistake No. 5: Trusting the client
Many of the worst security bugs appear when developers assume the client device will do the right thing. For example, code written to run in a browser can be rewritten by the browser to execute any arbitrary action. If the developer doesn't double-check all of the data coming back, anything can go wrong.
One of the simplest attacks relies on the fact that some programmers just pass along the client's data to the database, a process that works well until the client decides to send along SQL instead of a valid answer. If a website asks for a user's name and adds the name to a query, the attacker might type in the name
x; DROP TABLE users;. The database dutifully assumes the name is
x and then moves on to the next command, deleting the table filled with all of the users.
There are many other ways that clever people can abuse the trust of the server. Web polls are invitations to inject bias. Buffer overruns continue to be one of the simplest ways to corrupt software.
To make matters worse, severe security holes can arise when three or four seemingly benign holes are chained together. One programmer may let the client write a file assuming that the directory permissions will be sufficient to stop any wayward writing. Another may open up the permissions just to fix some random bug. Alone there's no trouble, but together, these coding decisions can hand over arbitrary access to the client.
Programming mistake No. 6: Not trusting the client enough
Sometimes too much security can lead paradoxically to gaping holes. Just a few days ago, I was told that the way to solve a problem with a particular piece of software was just to "chmod 777" the directory and everything inside it. Too much security ended up gumming up the works, leaving developers to loosen strictures just to keep processes running.
Web forms are another battleground where trust can save you in the long run. Not only do bank-level security, long personal data questionaires, and confirming email addresses discourage people from participating even on gossip-related sites, but having to protect that data once it is culled and stored can be far more trouble than it's worth.
Because of this, many Web developers are looking to reduce security as much as possible, not only to make it easy for people to engage with their products but also to save them the trouble of defending more than the minimum amount of data necessary to set up an account.
My book, "Translucent Databases," describes a number of ways that databases can store less information while providing the same services. In some cases, the solutions will work while storing nothing readable.