Home > tips, websites > 5 mistakes new web developers often make

5 mistakes new web developers often make

June 29th, 2008 Richard Bradshaw Leave a comment Go to comments
A graphical despiction of a very simple html document

Image via Wikipedia

Having talked to some university students who had taken computer science/IT degrees, I was amazed by how little they seemed to know about making anything that’s secure or even remotely logical. The group I met with primarily had been taught PHP. Having looked at some sites they were designing I realised 5 things that they had no idea they had done incorrectly, here’s a run down:

1. Don’t name your includes something.inc

Why it’s bad: Unless you specifically set .inc files to be parsed as php they are readable by just browsing to that page. Not good if we are talking about files that include the database username and password.

Easy way to fix: Name your includes .inc.php or put them in a folder called includes, and name them .php

Harder way to fix: Put a file named .htaccess in the directory with your .inc files, and add this line:

AddHandler application/x-httpd-php .inc

2. Don’t assume that because your site is small, it won’t be hammered by crackers

Why it’s bad: Although being hammered by crackers would be an unusual turn of events, for a website it’s inevitable. Bots exist with the sole purpose of cracking websites in order to add redirects to malware or spam to the site.

I built a small ruby site once, just as a test to see how it all worked. It had a comment form. I didn’t worry about sanatising the input, as I didn’t link to this site anywhere. Within a week there were about 4000 comments, all linking to spam. Luckily I hadn’t allowed javascript in the comments, so there wasn’t any evil redirections or anything, but the point is clear. Your site will be attacked.

How to fix: Read up on SQL injection and Cross Site Scripting (XSS). Use the PHP function mysql_real_escape_string to santise anything you are going to put into a database. Don’t allow html tags in your users input. Try to crack your site yourself – how would you do it?

3. Don’t just dump random code from tutorials into your site

Why it’s bad: I’ve seen sites before that link to 3 or 4 javascript frameworks, often to allow fancy animations and the like. This is fine, but there is a lot of crossover between them – I don’t see why you need more than one. These frameworks are pretty large – downloading even one to provide a trivial feature is questionable, but linking 3 or 4 is just madness.

Also, the golden rule of programming: if you don’t understand what code does, you probably shouldn’t be using it! (Caveat: unless it’s Perl – no one understands that!)

How to fix: Learn how to use javascript properly, or just stick to one framework.

4. Don’t ignore semantic design

Why it’s bad: It makes things harder for you. Honestly.

Using a semantic design means that headers are tagged using the H1, H2, H3 tags, paragraphs use p etc etc. Don’t inline style your headers with a font size and a font weight to get them larger and bold – use the way it’s designed to help you!

Use classes sensibly. Don’t put your red title in a class called redtitle – when you redesign the site that doesn’t make sense. Call it subtitle or something that describes what it is, not what it does.

Moving on from the basics, consider using technologies such as microformats to help you – these describe the information on your site more fully.

How to fix: Always separate content from presentation. Seperate CSS style sheets from HTML pages. Think about what purpose a page element serves, tag it appropriately and then use CSS to format it.

5. Don’t reinvent the wheel

Check what exists before you start. If you want to make a site, check out the existing tools: Wordpress, Joomla, Drupal etc. all have a head start on you – it might make more sense to take their code and design from there.

If you are using ajax, use a javascript framework – as new browsers come out with different support you can simply upgrade the framework rather than having to deal with these inconsistancies yourself.

Of course, if you are starting something totally new, a blank slate is often the place to start, but don’t waste time on work that doesn’t need to be done.

Conclusion

So, there you go – 5 things that I have definitely done before and hopefully some sound advice for people starting out.

Any further ideas, add them to the comments!

Links

mysql_real_escape_string documentation
40 signs you really area lousy PHP programmer

Existing starting points

Drupal
Wordpress
Joomla

  • Share/Save/Bookmark
Categories: tips, websites Tags: ,
  • Adam B
    Nice list. There are a few things I'd recommend in addition primarily for security. I've dealt primarily with PHP, but this can be applied to other systems as well.

    On production, always disable error output. Send your error messages to logs, but don't ever output them to the browser. Error messages, in addition to being unprofessional, can reveal details about your architecture that no one really needs to know.

    Second, ALWAYS filter and validate input. Assume every user is trying to destroy your server. Go with a white-list approach. If an input is supposed to be a numeric ID, make sure it's numeric only. Make sure to run input through sanitizing like mysql_real_escape_string(). And if you're doing queries, make sure that your web user has ONLY the privileges it needs - don't give it drop table access or anything. If you want to go further, use two web users - one for read that only has select access, and the write, which has select, insert, update, and delete. Only use the write user when you actually need it.

    Finally, when configuring your server, make the docroot as limited as possible. That is, stuff like include files and template files (if you have them) should not be accessible through the server.

    Hope these tips help!
  • Good point with number 5. These javascript/ajax frameworks have been thoroughly tested in multiple browsers.
  • D
    I learned #2 the hard way. Built a site for a local dancing club in the beginning of my career, and didn't bother to worry about security.

    2 months later I get a call, that their guestbook was full of spam, and that it had broken completely recently (a meta redirect inserted in the comment).

    I quickly added a captcha and made sure no SQL or Javascript injection was possible etc. This is a given today, no matter how small the project.

    Good read.
  • Shouldn't that be "Don't ignore semantic design"?
  • Edited to fix that... good thinking!
  • Ryo
    Nice posting, and so true. In addition to 3, one should be warned, that if you embed javascript you should first be aware of what you doing. Not only site statistics could eventually be transfered to someone else. At worst, even things a user entered could be send out. So, use only serious sources, and try to learn as much as you can about a specific service. Especially for Web 2.0 things, and that is not easy, even for a pro.
  • Yeah - if you allow arbitrary code to run on your server, it's not your server anymore...
  • pcdinh
    Drupal code is bad styled too. Dont look at Drupal code and learn from it.
  • testerman5
    Also, avoid learning grammar from the internet.

    You do have a point, however poorly written it may be. :p
  • Good work, But in my case, the above issues doesn't cause more problem to the website except point no 1.
  • Wow. This is all excellent advice, even for us pros (who all too often forget the basics). On "Don't reinvent the wheel," it's worth mentioning that learning about pre-existing platforms is a marketable job skill in and of itself. For example, I learned WordPress because I like to blog. However, because I developed that expertise, I now do a lot of lucrative side work setting up, customizing, and debugging WordPress installations. Learning existing tools can be well worth it from more than an efficiency standpoint.
  • vinodpahuja
    If Wheels were never reinvented
    we would be still using the tyre of rock
  • I think it is acceptable to reinvent another model of the wheel
  • reinventing the wheel shouldn't be a problem for a company specializing in wheel development. why should bob smith try to make the next GoodYear tire clone out of play dough and an etch-a-sketch.
  • nice useful article.
  • Thanks!
  • ktb
    A thing I learned;
    Use many functions instead of copy and paste, and use stlye classes instead of coyping single style attributes^^
  • Thanks for the article!

    A point though about naming of include files - the best solution is to place them in a directory that's not directly accessible to the web. Your PHP scripts will still be able to include them just fine.

    If you do have to have them in a web-accessible directory for some reason, at least place them in a directory all of their own. Then place a htaccess file in there containing the following:

    <Files *>

    order allow,deny

    deny from all

    </Files>


    It's a mistake to think that giving your includes .php extensions makes them entirely safe. Should anyone ever try to access them individually (which is fairly unlikely anyway) they might not see your raw PHP code, but that code would be executed, with unknown consequences.
  • #5 - so true
  • imgriff
    #6. Don't forget to spell check before posting your article *nudge nudge*
  • Good post, I will admit I've done a couple of them before. Fortunately I use Drupal now and it comes with Jquery which has a lot of the Javascript I need built in.
  • Poppo
    1 Mistake You Made:

    Don't make your section headers smaller and less bold than your section content.

    Why it's bad;

    Because it's very hard to skim your page for the start of the next section.
  • Mentioning some details about mysql_real_escape_string won't be a bad thing I guess...
  • Make sure your server is well secured, here's one of our guides: http://vpsmedia.com/articles/?p=25
    its specific for Centos 5.2 but it should give anyone a pretty good idea.
  • ya for sure these mistakes happen alot
blog comments powered by Disqus