On Stack Overflow, I see a lot of PHP code in questions and answers that have MySQL queries that are highly vulnerable to SQL injection attacks, despite basic workarounds being widely available for more than a decade.

Is there a reason why these types of code snippets are still in use today?

  • 38
    blame it on badly written online tutorials. more often than not, people are just copy and paste whatever code they find on the net. JavaScript is also another victim of such practice.
    – KJYe.Name
    Mar 15, 2011 at 14:12
  • 36
    Blame the blogs. Oh, and W3Schools... Mar 15, 2011 at 14:12
  • 14
    Yes, absolutely W3Schools - see w3fools.com Mar 28, 2011 at 12:30
  • 2
    I constantly see people warning about sql injection - so I dont even think the premise of this question is valid. It is a high priority. Dec 19, 2011 at 7:48
  • 3
    What I'm seeing in a lot of the answers is the that it's easier to teach critically broken PHP than it is to teach, well, PHP that's not critically broken. You cannot accept that argument and still claim that PHP is not a bad language
    – user16764
    Dec 1, 2012 at 0:00

11 Answers 11


I think it's mostly due to a) ignorance b) laziness. Beginners usually don't know much about sql injection, and even when they hear about it, they ignore it because it's so much simpler and easier to code that way.

  • 8
    I've tried to correct such things elsewhere, only to be told that it's not relevant for the problem at hand. So because a lot of people prefer a simple hack to a slightly more complex good solution, bad examples are left alone.
    – l0b0
    Mar 15, 2011 at 14:25
  • 6
    Most people don't really care about SQL injection until they get hit with it. Then suddenly they're wondering where their tables went. Mar 15, 2011 at 14:39
  • 1
    The other reason is that SQL injection is not always viewed as a relevant concern for internal apps. (Not that they're right.) Nov 26, 2011 at 4:59
  • 1
    Don't forget that Answers are there to answer the question. Often it is pseudo-code (or SQL) that is intended to answer the question, not necessarily provide a safe and secure copy and paste solution (despite how the answer may be used in reality).
    – user43349
    Dec 19, 2011 at 18:52
  • 1
    @l0b0 I know someone who got people to take SQL injection fixes seriously by actually demonstrating an SQL injection attack against the current production code.
    – user16764
    Dec 3, 2012 at 18:32

PHP deliberately makes it really, really easy for people who know very little to create useful dynamic web pages. This means that PHP is going to attract a lot of beginners, who create something useful, learn from other useful looking examples, and turn around to teach others how to do this cool, useful thing. The result is a lot of bad code, and a supply of programmers who don't know any better.

It only makes things worse that a large fraction of competent programmers want nothing to do with PHP. This reduces the base of experienced people who are willing to teach others better. But why do they avoid PHP? Well for a combination of factors. In part they don't like dealing with the language warts. And in part it is because they would prefer to work with good code, and there isn't a lot of good PHP out there.

This exact constellation of problems used to inflict Perl. As a shining example consider the case of Matt Wright, an enthusiastic teenager who set out to provide many useful, well-documented and easy to install CGI scripts back in the 1990s. Unfortunately he understood nothing about security, and neither did the people who wanted to use his stuff. The result was the Matt Wright Script Archives, which was an endless stream of security problems for early CGI scripts. Despite efforts like http://www.scriptarchive.com/nms.html, the problem didn't improve for Perl until shared hosting providers made PHP more convenient than anything else. That lead to the problem moving from Perl to PHP.

  • As you said, the problem is not perl or PHP, its that these languages let beginners do a lot of things, which is good, but don't always provide ways to do them well that are as obvious.
    – Zachary K
    Mar 15, 2011 at 15:48
  • 2
    @ZacharyK: Isn't that then the language's fault by default? Mar 15, 2011 at 23:27
  • 6
    @tomalak-geretkal: You use the word "fault" as if making it possible to get stuff done is a bad thing. The same characteristics that lead to lots of bad code also lead to a lot of real problems solved. It is not clear that this is a bad thing on the whole.
    – btilly
    Mar 16, 2011 at 0:26
  • Re 'fault': if HTML (or rather the browsers interpreting it) had been as fault tolerant as XSL, there would never have been a world wide web...
    – Benjol
    Dec 19, 2011 at 8:33

Unfortunately there are tons of more-than-bad PHP tutorials out there and some older PHP books also sucked at telling people to write proper code (not using register_globals etc.).

Additionally, with magic_quotes_gpc being enabled in the past, people didn't care about escaping because "it simply worked".


Personally, I believe PHP is easy to use, so naturally it's easy to misuse.


As a human, and a programmer, I find it remarkably easy to make mistakes, and overlook certain things, especially when pressed for time.

It's easy, and perhaps all too tempting, to blame a certain language, for being too accessible for its own good. But that would be glossing over the larger problem of human fallibility, regardless of the language chosen to program in.

Granted, we've come a long way since assembly language, and I think I would be far more productive programming in a more modern language, such as PHP, Python, Ruby, or Java.

PHP (and other scripting languages) have in fact lowered the barrier to entry. That may mean that more newcomers to programming try PHP first. But that certainly does not also mean that all PHP programmers are somehow less qualified, or less able to learn from their mistakes than programmers of other languages.

Rasmus Lerdorf created PHP in its original form back in 1994, it has evolved considerably since then. In its most modern incarnation, it supports object oriented programming, as well as superb frameworks, such as Symfony. PHP as a language has broken free from its original constraints, and has grown to offer great flexibility in how programmers can choose to use it. You can use it to create a 9,000 line script of spaghetti code, or you can use it within the context of a modern, MVC framework, such as Symfony: it's your choice!

I strongly suspect that security vulnerabilities are not restricted to a single language. It's tempting to write off all PHP programmers as somehow less capable, or more prone to writing insecure code. But I wonder how much of that is language bias, and how much of it is fact?


I think part of the problem is people who simply copy code without bothering to learn what they are doing, but really to my mind the way we teach porgamnming is broken and it is one of the reasons why there is so much bad code. We teach syntax out of context and so the beginners don't know when to use something and when not to or what problems the syntax is intended to solve and what problems it is not intended to solve. SO they use a hammer when a wrench would have been the better tool.

So for instance instead of teaching just syntax, you organize the course like (Clearly there would be more steps, this is just a basic example of building from basic to more complex problems rather than just teaching syntax):

  1. This is how you set up a basic web page
  2. This is how you make the web page pull data from a database
  3. This is how you send data from a web page to a database
  4. This is how you make sure the right data is sent.
  5. This is how you protect your database from malicious data entry
  • that's more or less the way I was teached php +1
    – Rémi
    Sep 11, 2013 at 19:04

I think you'll find a similar amount of MS SQL + ASP/ASP.NET examples that are just as vulnerable.

I feel the problem partly stems from the fact that when you're trying teach something, say filtering data using a WHERE clause, then you really don't want to clutter your example by properly escaping your query string or using a parametrised command.

I've been training developers for many years and I can empathise with people who write horrible code in tutorials. Sometimes that's the most easily understood. However, on an aside I always point out code that's vulnerable and make it into an interesting side topic.

  • 6
    That shouldn't be an aside. That should be part of the basic lesson. Possibly with a big, fat, warning about the wrong way to do things. People tend to cut and paste what they first see, and you really want that to be the right way to do things.
    – btilly
    Mar 15, 2011 at 16:40
  • Certainly in the .NET world parameterising is pretty straightforward these days and should indeed be 'page one' stuff.
    – Alan B
    Sep 11, 2013 at 16:32

PHP's original author, Rasmus Lerdorf, in his infamous blog entry advocates "no-framework" development. Although for SQL queries he uses PDO, so there is no risk of SQL injection. Still quite ugly and obsolete comparing to modern MVC frameworks with ORMs layers.

  • 5
    It's certainly possible to over-engineer sites with complex frameworks that you just don't need. I'd say that Rasmus's suggestions verge on the criminally dangerous, but there's definitely a sane middle ground. Mar 15, 2011 at 23:27
  • nowadays using ORM isn't over-engineering; it's standard. So is using MVC pattern.
    – vartec
    Mar 15, 2011 at 23:54
  • 3
    @vartec: It's hardly "standard" just because all the sheep are using it (and, for what it's worth, not even all the sheep are using it). For small scripts it can easily be over-engineering. Mar 16, 2011 at 0:40
  • 1
    @Tomalak: it standard, because that's the way to implement clean and sustainable projects. "small scripts" tend to grow over time and turn into unmaintainable monstrosities.
    – vartec
    Mar 16, 2011 at 11:29
  • 2
    @vartec: I think you've misunderstood the meaning of "standard". Mar 16, 2011 at 11:30

You can blame this poor practise on PHP itself. Legacy versions of PHP (up until circa 2006) would escape all GET and POST input variables so that they were suitable for database query interpolation BY DEFAULT. See http://php.net/manual/en/security.magicquotes.php

  • 2
    There was a time it would escape ALL variables as if they were going into MySQL specifically, whether they ever were or not. Note to language designers: when you find yourself having to implement stripslashes(), you've already done it wrong.
    – Dan Ray
    Dec 19, 2011 at 13:14

Don't confuse the purpose of a tutorial, which is to demonstrate something simply, with what should be done in a production environment. For example, most tutorial code I have written has little or no error/exception checking. I try to remind the reader that the code only demonstrates how to perform a specific task, not how to cover all the possible outcomes.

  • 3
    Sorry, but absolutely no example code should ever mix mySQL queries with PHP. That's simply doing it wrong.
    – Raynos
    Nov 26, 2011 at 4:30
  • 1
    And irresponsibly. Nov 26, 2011 at 10:48
  • -1 for most tutorial code I have written has little or no error/exception checking..
    – yannis
    Nov 27, 2011 at 1:50
  • I can see the OP's point. Irresponsible is, when an employer hires a guy who lacks knowledge about SQL injection and the like.
    – Raffael
    Nov 27, 2011 at 12:25
  • I think this approach is defensible if you include comments directly in the code saying "Do not use this in production!". That way the copy/pasters have no excuse.
    – Benjol
    Dec 19, 2011 at 8:47

When i was learning PHP i looked at some these PHP+MySQL books, and yeah i feel that it contributes to that bad practice. But i have sympathy, becuase they are teaching the language, not good programming practices. Otherwise where would it end?

  • 2
    But when you are teaching the language, you should still use the preferred APIs in your examples. Like always use the parametric form of SQL queries, possibly with a footnote like "Don't ever think of using interpolation to build SQL instead. It seems a little easier, but it's extremely prone to security vulnerabilities."
    – Jan Hudec
    Nov 25, 2011 at 12:00
  • Yep, good points. Footnotes would be a good reminder, and that goes for the online tutorials as well. In all seriousness though, it would be great if book authors of all languages could incorporate the advice from OWASP into beginner texts. Even just as a reference. The OWASP Foundation do a good job. Nov 27, 2011 at 5:56
  • @indifferentDrum: You can teach people to drive with their feet, too -- doesn't mean it's a good idea. Dec 1, 2012 at 10:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.