Starting Secure Development

As I’m trying to get back into some more regular article writing for the security tutorial site, I thought I’d ask on Twitter for some of the things people might be interested in reading. I thought I’d gather them all up and share them here (since Twitter is sooo good at tracking this kind of thing…). There were some good responses and some things I hadn’t thought about yet:

> Top 10 pitfalls and how to avoid them. @calevans
> how to actually filter input and escape output correctly. @skoop
> I’d like the ability to answer to the question “Is it safe?” with confidence. @AmyStephen
> Data sanitization, escaping, and authentication. @codeguy
> how to test for secure code. @scottmattocks
> One of my largest stumbling blocks has been learning how to write proper (library-less) templates in a secure and flexible manner. @mkmcdonald

You can see all of the responses here. There’s a few articles related to these posted already:

If you have any other suggestions let me know!



  1. Sounds like a nice list. Especially the “Input filtering/output escaping the right way” and testing secure code is something I’d look forward too.
    Probably ‘how to answer “is it safe”‘ too!


  2. What I am somewhat amazed by is the amount of basic security lessons that are ignored in web development.

    Almost every open source app I know stores user information[userid, username, password, email address, and basic user profile info – for some definition of basic] in a single record. Then they put a lot of effort into picking just the right password hash function to “secure” data that never should have been there to begin with! This is an old school unix “oppsie” with a tried and tested solution. Never store passwords in the same place as other data that will be needed by many subcomponents of an application. Passwords should be stored in their own area with strict access controls. For mysql, this means put them in their own table at a minimum so an accidental user dump doesn’t expose the data. Preferably, the table should only be accessible by a seperate mysql userid which can only access that table – and then create a stored procedure which retrieves a single record and use that to authenticate logons.

    That avoids a whole slew of sql injection attacks – and it’s a well tested, decades old solution.

    Yet PHP app after app repeats the mistakes of the past rather than learn from them.


    1. Agreed – it’s a pretty common practice that’s not helped by the multitudes of articles and tutorials out there preaching the same things. It’s a tricky thing because with beginners, there’s a balance between introducing them to the topic and not getting too wrapped up in the more correct password storage methods. I’m a big advocate for teaching people how to do things right the first time, though, and not pandering to the lowest common denominator.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s