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

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 3

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.