All posts tagged ‘Databases’

No programmer is perfect, but some mistakes are more dangerous than others. While some mistakes might just slow down your site, others can open up vulnerabilities that expose your code, your database and even your users to all manner of attack.

To help you identify the more serious errors common in programs of all types, a group of top software security experts in the US and Europe have released their Top 25 Most Dangerous Programming Errors.

Unsurprisingly, cross-site scripting vulnerabilities and improperly handled SQL top the list of common and dangerous mistakes. Remember kids, sanitize your database inputs; you just never know when someone is going to name their child: “Robert’) DROP TABLE Students;”

While not all the errors in the list are common in web programming, some of the more serious things are concerns for web developers — cross-site request forgeries, missing encryption of sensitive data and unrestricted file uploads are all common web programming issues.

Also interesting is the weaknesses by language section, which breaks down common mistakes in PHP, Java, Perl and C/C++. No doubt web developers would like to have seen Python and Ruby in that list, but it should at least be useful for PHP and Perl programmers.

As a computer science term, data binding is the substitution of a real value in a program after it has been compiled.

For example, during compilation a compiler can assign symbolic addresses to certain variables or instructions. When the program is bound, or linked, the binder replaces the symbolic addresses with real machine addresses. The moment at which binding occurs is called “bind time” or “link time.” In dHTML, data binding allows the client to look into a database and retrieve the content. This data can be automatically displayed in your table using the HTML data binding extensions, or you can manipulate the data with a script.

Have you ever written a database call that went something like… select * from posts where id=3;? We probably all have, but it’s bad for several reasons. Four of them, according to a programmer that goes by pizza_milkshake.

To database administrators and advanced programmers, this may not come as news. Even many seasoned coders could use a reminder not to be lazy.

pizza_milkshake’s Four Reasons Not to Select All

If you include the field names, your code is self-documenting

When a field name changes, you want to know with a query error, not later

Asking for more than you need is just wasting resources

Without naming the fields, you can’t be certain of the order you’ll receive them

I hope these reasons are good enough to encourage your next query to not start select *.