Tag: security

I’ve just come across 10 Principles Of The PHP Masters which has the following points (with my commentry added):

1. Use PHP Only When You Need It (Rasmus Lerdorf, creator of PHP)

PHP, like Perl, Javascript, ASP, C, Ruby, Python, C++, C# etc has it’s limitations and is more suitable for some jobs than others. Whilst it’s possibly to run PHP in the web browser, you wouldn’t really want to (as you’ll need to get your visitors to install a PHP interpreter on your machine) – likewise, you wouldn’t use PHP on embedded systems due to its size. However, if you are writing a big web application, you’ll be a masochist if you were to use Perl nowadays (back when I was a Perl web developer creating web applications in Perl – PHP was still in its very early stages) and you’ll be hitting a large performance penalty if you were to get the server to interpret Javascript for each page.

2. Use Many Tables With PHP and MYSQL for Scalability (Matt Mullenweg, creator of WordPress)

If you store a lot of data in a single MySQL (or PostgreSQL) table, then it’s going to take a long time for the server to search through the data to pull up a single row: if you have multiple tables, it’s got a smaller data set to scan

3. Never, ever trust your users (Dave Child, the brains behind Added Bytes – previously ilovejackdaniels)

This isn’t just a PHP issue – never ever trust user input more than you really really need to: otherwise, that way leads to security exploits and it’s best to write secure code. If you’re expecting digits, use preg_replace to remove anything that isn’t a digit, if you’re only expecting letters A-z, then again strip out anything that isn’t a letter. Work on the premise “what do I want to keep” and disregard the rest: I’ve seen people go down the “what do I want to get rid of” route instead and then get most upset when I say “well, what about this character?” and they have to add it to the “get rid of” list

4. Invest in PHP Caching (Ben Balbo, writer on Site Point)

Database calls are more processor/hard drive “expensive” than reading flat files off the hard drive, fetching remote pages is more processor/network intensive than reading them out of a local database (or a hard drive), counting database rows is slow: but reading a “row count” table or flat file isn’t, parsing templates (especially using regular expressions) are slow – reading prepared/precompiled files isn’t. Spot a pattern?

5. Speed up PHP Development with an IDE, Templates and Snippets (Chad Kieffer, author 2 tablespoons)

Personally, I prefer hand coding than using IDEs (Integrated Development Environments) as most of them get in my way: things like auto-closing brackets (I’ve been programming so long that I automatically close them myself – and I don’t want two sets of closing brackets) and within editor debugging usually doesn’t take into account the different environments in use (it’s often I’m developing on Windows XP/Vista, saving the file which is then picked up by a Virtual Machine for testing running Linux and all the appropriate PHP modules before been sent live to a physical Linux machine). However, I may just read his getting started with Eclipse guide.

6. Make Better Use of PHP’s Filter Functions (Joey Sochacki, author Devolio)

Filters (as detailed by Joey) are new on PHP5: so if you’re still writing for PHP4 environments or you can’t guarantee that the server administrator has installed the necessary PECL module – then you’re a bit stuck. I prefer to “roll-my-own” validation/filtering routines anyway – at least I’ll know how they work and not be shocked when bugs in the filter affect my code.

7. Use a PHP Framework (Josh Sharp)

See point 8

8. Don’t use a PHP Framework (Rasmus Lerdorf, creator of PHP)

I prefer not using a framework myself as they tend to be overkill for most tasks, don’t do exactly what’s needed: and, over the years, I’ve got a collection of routines on my hard drives (and memorised!) which do most of the common options. As Rasmus shows in an article, frameworks are also quite slow compared to “pure PHP” – because, of course, it’s a “generic tool” and isn’t optimised for “this” particular scenario.

9. Use Batch Processing (Jack D. Herrington, author of PHP Hacks book)

Why process building stats and things “on the fly” which slows down the user experience – why not run them automatically at 2am? In my previous work, I had to produce a sales commission report of 60+ sales personnel out of a months sales figures (which was several hundred thousand “items” per month) and work out which items attract what commission and what each sales person should receive. Doing that sort of processing and data extraction is slooow (even with a perfectly tuned optimised database) – however, running a batch process overnight which just extracted the sales made in the last 24 hours by each sales person (ignoring ones sold online for example) and store that information in a separate table meant sales reports could be produced within a minute or two instead of an hour or two (it still took a little time as some of the commission data was “dynamic” and had to take certain other things into account).

10. Turn on Error Reporting Immediately (David Cummings, HannonHll)

If you have PHP error reporting turned to the maximum during development (so you get the tiniest little issues highlighted immediately), it’s a lot easier and quicker to find potential issues and resolve them – before it’s deployed to a client. Turning error reporting to just “ERRORS” means you’ll miss the vital warnings which could save your code!