PHP is not my first choice when creating a web application, but I am frequently called upon to work with an existing app that was created in it. I know that there is no reason to think that PHP coders are any 'worse' than any others overall, but the realities are such that when my creative/marketing agency clients had to find someone to create a web app for their clients before they knew me, they took what they could find.

So, first; I can't recall the last PHP app I've worked on after someone else which did not have obvious SQL Injection vulnerabilities in it. Pretty much every SQL command is built by concatenating strings, and if we're lucky, some attempt is made to escape some of the input, some of the time. I can not count on one hand the number of times in the last year I've been asked to fix an error in an app that was discovered when someone typed in a value that had a single-quote in it. I've also seen too many apps that set a simple sesson cookie value (such as a cookie "Admin" with the value "1") to denote that someone has logged in to the CMS.

I can understand how it happens that someone is lazy or ignorant, and things like the above happen. But something I came across last week flabbergasted me. So much that I had to wonder; is there something I'm not seeing here?

Basically, the app managed a list of profiles of members of the business served by the web site. There are the expected tables in the database for the profiles, with auto-generated ID values serving as primary key. There is a central page which lists all the profiles, and it builds that list from what is in the database. All fine so far. (Well, aside from the fact that none of that code is protected against SQL Injection.) But here's where things get weird;

The URLs for the links in the list are built from the full names of the folks, with no spaces. And no; URL Rewriting is not being used. Individual PHP files are created matching those names manually, and the only difference between each of those files is that each one hard-codes the ID to the member whose profile is to be displayed.

The only possible reason I can even conceive of for this is some attempt at SEO. But from a quick look at the site on the whole, I can assure you that was not something the original coder was thinking of. Was it an attempt to avoid having ID parameters passed around, thereby reducing SQL Injection surface? I dunno; but again, from the whole site, no - that does not seem to have at all been on their mind.

So, I'll be fixing that soon. Maybe sometime soon, I'll have an epiphany and realize why it was done how it was done. Or, maybe not...