Is a freelancer liable for poor code he inherited from someone else?

Question

As a freelancer, I inherit a lot of poorly developed custom web projects. Most of these projects do not safeguard against XSS and SQL injection. On some of these projects, I've been the sole developer for over 1 year. When clients ask me to add new features, I do it without making significant changes to the underlying system's architecture.

So for example, if a client asked me to build a registration page on a limited budget, I do so re-using the system's Data Access Objects which do not prevent SQL injection, and I render the pages with the system's View Objects which do not sanitize the code for XSS.

If at a later time, a hacker exploits these security breaches in the registration page, am I held accountable? I was never asked to re-write the systems Data Access Objects or the View Objects. And because the client is on a limited budget, they won't pay me to write a new DAO or View for the system. So does it automatically become my fault the day I decide to inherit such a disastrous project?

And what if there are other parts of a system I rarely touched? I may have gone in to change some of the text on the views, or added a new if statement in the controller. Once I've "touched" something, does it mean I am liable for the entire module until I retire from the project?

Answer 1

Tell them about any issues you see, and include an estimate of the hours involved to fix them. Put it in writing, and you've put the ball in their court. They can't hold you liable for their own failure to pay attention to your warnings.

Let me add that if I could fix many of these problems in 15 minutes or less, then I would, just as a matter of personal pride in my work.

Answer 2

I can't answer from a legal perspective; that'll depend on the written and case law in your jurisdiction. From an ethical one, though, the least you should do is identify the flaws and their potential impact to your clients. Give them an idea of what could happen if those vulnerabilities were exploited.

Answer 3

When I freelance, I do the work I'm paid/asked to do and advise on work that I feel should be done.

That's actually how I approach most of what I do. I'll do exactly what I'm asked, but as a professional I almost always offer up my opinion on the situation.

I certainly wouldn't say you are directly responsible for it, but it wouldn't be very professional to not say anything about it.

Oh and I'm not suggesting that you have to weedwack your way through the entire codebase to find any potential issues...just that if you come across them in what you are doing, don't sweep em under the rug.

Answer 4

When taking over a new project I would make it very clear to the client that I am not liable for errors in the original source unless they also wanted to pay me for my time to do a full code review. To protect yourself, make sure you keep a copy of the original code as you got it.

Answer 5

I think you should make your client well aware of the situation. Let them know what risks are in the current system they are running, and how much it will cost to fix it and what the risks are if they don't.

I don't think you can be liable (but I am not a lawyer - contact one if there is a real pressing legal issue) for pre-existing problems IF you make the client aware that you are aware of them.

How is this handled in other situations? If an engineer comes across something very poorly constructed but is only given a budget for a very small tweak or fix, is he still responsible for all the other problems?

Answer 6

There are two separate questions here:

How do you protect yourself in this situation?

You make sure you have a copy of the original code, and use a good source control system, so that if questions arise, you can illustrate clearly that this isn't code that you wrote, but that was present before you started.

How do you do right by the client in this situation?

You ask the client up-front what kind of analysis they'd like you to do: Potential code improvements, security fixes, etc. Think of categories you can give them to give a good picture of what you'll be reviewing and what kinds of things you could potentially find.

Why up-front? Because otherwise you'll get car mechanic syndrome, where you take in your car, and the mechanic says "Oh, by the way, we found this problem over here" and you feel uneasy because you're not sure if it's real or not. But if you ask the mechanic to give it a good going-over everywhere, at least you'll feel more comfortable with it if he finds something.

Likewise, if you get the up-front OK to look for stuff like this, then you can make a list and show them the code and illustrate the problems, and you look like a professional doing analysis rather than a slimy mechanic trying to make an extra buck for questionable work.

Answer 7

Spec It Out

When freelancing you should always provide the client with a fully detailed spec of work broken down into the smallest sections you can manage and your estimated hour requirements for each section.

If you notice glaring issues in their current codebase that you would be willing to remedy, create a secondary specced estimation of certain things you believe you could fix and make sure to include why it's important to fix the issues.

---

Best Case Scenario

In the best case scenario you get some additional work and the client gets an improved application.

---

Worst Case Scenario

In the worst case your client declines your quote on fixing their existing bugs/security holes/code bloat. This is not a bad scenario to be in as you have cleared your liabilities in the event something goes wrong in the future. It also gives you a good indication to not pursue further work for the client as they clearly has no concern for security or quality of work. Just be glad when you have finished the project.

Answer 8

You can atleast prevent SQL Injection and XSS from front end so its not a big deal.