I've been hired by someone to do some small work on a site. It's a site for a large company. It contains very sensitive data, so security is very important. Upon analyzing the code, I've noticed it's filled with security holes - read, lots of PHP files throwing user get/post input directly into mysql requests and system commands.

The problem is, the person who made the site for him is a programmer with family and children who depend on that job. I can't just say: "your site is a script kiddie amusement park. Let me redo it for you and you'll be fine."

What would you do in this situation?


I followed some good advice here and politely reported to the developer that I've found some possible security flaws on the site. I pointed out the line and said there could be a possible vulnerability for SQL injection attacks there, and asked if he knew about it. He replied: "sure, but I think that to exploit it the attacker should have information on the structure of the database; I have to understand better".

Update 2:

I said that's not always the case and suggested he follows this Stack Overflow question link in order to deal with it properly: How to prevent SQL injection in PHP? He said he would study it and thanked me for telling him before. I guess my part is done, thanks guys.

  • 29
    I'd really enjoy a solution that does not involve ruining someone's life. I'd leave this alone but I also know such a security hole could, too, ruin some people life. Complicated.
    – MaiaVictor
    Commented Mar 4, 2013 at 19:37
  • 18
    The attacker could use the exploit to get the information on the structure of the database. No SQL injection vulnerability should ever be downplayed.
    – Dave Rager
    Commented Mar 4, 2013 at 20:07
  • 17
    Show him how to exploit some vulnerability without using any knowledge of the database. That will scare the sh*t out of him.
    – Euphoric
    Commented Mar 4, 2013 at 20:14
  • 74
    I just want to say good job for looking out for another person/programmer that you don't know. It doesn't make it any less of a terrible thing to ruin their livelihood because they made a mistake and you don't know them, and I commend you for taking it into account.
    – Steel
    Commented Mar 4, 2013 at 20:28
  • 8
    @Dokkat The issue is one of balance. From a programmer's perspective, the poor quality programmer with a wife and child has actually endangered the company, and thus the jobs of many employees with wives and children. Also, the issue is often complicated by the emotional issue of "Bad programmer does something that makes my life harder. Now I have to miss out on spending time with my family. They are more important to me than he is. This seems unfair." That's an irrational response, but folks be folks.
    – deworde
    Commented Mar 5, 2013 at 9:41

7 Answers 7


First and foremost here, the priority is to close the security holes.

If you're working directly with the engineer who wrote this, document everything and give it to that engineer.

If not, tell your employer the security issues are bigger than initially thought and that the site needs a lot of work. Ask to work with the main developer who's on the site, and offer to teach them about PHP security (don't promise to make the person an expert, but do offer to train them in everything you know) so that person can take it over after you're done.

Don't make this a "this guy is bad, fire him" issue. Approach it from the perspective of "Hey, I found some potential bugs that need fixing stat, which seem to be coming from some ignorance/common misconceptions about site security. I'd also like to talk to your development so we can improve your site and hopefully avoid more of these issues in the future."

  • 1
    Great answers overall. The topic is subjective, so I'll mark yours as it was the most accepted by the community.
    – MaiaVictor
    Commented Mar 5, 2013 at 7:07
  • 1
    If you are working WITH the engineer, but being paid BY management, should you not report TO management? What if the engineer thanks you, but the moment you leave, destroys the report?
    – Konerak
    Commented Mar 6, 2013 at 8:28
  • Either tell both, or tell the engineer first, and verify that bugs are being created and tracked in whatever system they use. If bugs aren't created, tell management. Commented Mar 6, 2013 at 15:59
  • 2
    I liked this answer better: programmers.stackexchange.com/a/189206/28351, because for the employer the priorities are different. First report the security holes, then fix the small bug.
    – nalply
    Commented Mar 7, 2013 at 19:28

There's a difference between ignorance and incompetence. There was a time when you didn't know what SQL injection was either, and there's no reason to believe the original programmer isn't capable of fixing the problems once he is made aware of them.

So tell them. Be specific and objective, and make yourself available to answer questions, provide examples of exploits, and recommendations for fixes. If they still don't get it after that point, the most you can really do is not put any of your own personal information on the site.

  • 26
    +1. Ignorance can be fixed. Incompetence is a career for some! Commented Mar 5, 2013 at 2:01

Your job isn't to redo the site for him. It's to fix the small bug. However, if you've noticed security issues that should be fixed you can bring it up with the site owner and offer insight on what the problem might be.

Don't berate or talk negatively about the original developer or comment on how horrible the code is. Be respectful and professional. You can offer to work with the developer to resolve the issues. Don't try to fix it yourself or offer a solution unless you've been contracted to address the problem. If they follow your advice and you're wrong they could come back on you.


First and foremost - fix the thing they hired you for. If you don't do that, then you'll be perceived as the type of consultant who's interested in making more work for themself, rather than getting the job done.

Along with the fixes, you need to give them a list of the stuff you've noticed that's wrong from a security perspective, and why these things are wrong.


It won't do anyone any good to not report the issues. If you had a specific task you were hired for complete it but document other security issues as you see them and report them to the appropriate individual, probably the individual that you are reporting to for the task you were hired for.

This is a situation where strong soft skills are going to come in handy as to handle this with tact will require not putting down the work done by others on the site and not making the developer feel as if you are questioning his talent.

Obviously avoid words like "crap, bad, poor, riddled" when referring to the code/flaws and similar words for the developer that wrote the site.

  • 4
    I would add: make sure the developer is aware of the severity of the flaws and how they can be exploited. Taking the time to launch a controlled 'attack' on a local machine with this developer present could do much to educate him on the problem, which leaves openings for you to suggest ways to harden the code. Commented Mar 4, 2013 at 19:38

In addition to the other answers what you might want to do is point the developer at some resources on how easily SQL injection issues can be exploited, for example sqlmap which is an automated SQL Injection exploitation tool.

What I've found to be effective in demonstrating the seriousness of this kind of issue in the past is showing what can be done with it, so if you run something like that against a dev. copy of the site to show it extracting data etc you might convince them of the seriousness.

  • 4
    Be aware this has some risks, in that you can be made to seem like a "hacker". Management people do not necessarily understand terms like "existing vulnerability", "development copy" and "white hat security analyst"
    – deworde
    Commented Mar 6, 2013 at 10:14

First and only; Management does not want to hear about problems. I got fired from the Office of Personnel Management (security clearances for the white house) because I pointed out how insecure their system was. That was awhile back, but management attitudes have not changed.

Address the problem with the developer, via email so you have a trail, then walk or run away. When they do eventually have a problem, as a contractor, they will try to blame you, regardless of having any involvement even remotely connected to the problem.

Having a problem as fundamental as a SQL injection, indicates they were cheap when they initially developed the system, and odds are they are at best cheap now. Get what you can from them while they are still in business, but seek business development elsewhere.

  • 3
    "Management does not want to hear about problems" -- add some reasoning / references to support your assertion (which sounds plausible to me but this doesn't really matter) and I will revoke downvote
    – gnat
    Commented May 11, 2013 at 22:19

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