Help Developers On-board Another Team's Web Project

March 3, 2017
Written By Felipe Kettle

It is a nerve-wrecking task for businesses and agencies to transfer control of a custom-built web application between vendors. From a technical perspective, the risk lies in the fact that your team may not have perfect insight into what goes on under the hood.

We have inherited a lot of custom solutions built by other vendors because the owners were dissatisfied with previous service. We have also helped other organizations successfully transfer ownership of technology between vendors. Below are items we often raise with the management team during the audit and transfer process.

Is Your Solution Secure?

Customers value their privacy, businesses value their data and efforts must be made to protect those things. Technical solutions must follow certain best practices to maintain that security. In a poorly developed solution, these are the most common security issues:

  • Non-Encrypted Passwords – Inexperienced developers will often store user passwords in the database in human readable format instead of an encrypted format. This is dangerous because the moment an unauthorized user gains access to this data, they can exploit it in disastrous ways for your customers in any other digital application including but not limited to banking systems, government accounts, social media sites etc... This is the first thing we look for and correct on behalf of our clients.
  • SQL Injection – This is a common problem in older PHP projects that we have seen. Previous developers tend to not use parameterized queries, stored procedures, or other measures to mitigate this risk.
  • Cross Site Scripting – Although most sites often validate standard data fields such as email, phone, zip, postal, country etc…, they often fail to sanitize other free form text fields for forms of code injection that allow for cross site scripting hacks.
  • Database Privileges – Previous developers often overlook the need to reduce database privileges to only what is necessary. By leaving the database permissions too permissive, it is more vulnerable to attacks.
  • Does the Solution Stink?

    Code smell and design smell are markers that indicate low quality and usually indicate that there are larger issues lying beneath the surface. Some examples of smelly code or design are:

  • Is code easy to read and structured?
  • Is the code organized in a way that is not logically repetitive or otherwise "copy and paste"?
  • Do variables and functions have meaningful and intention revealing names?
  • If the answer to any of the above is "no", there could be cause for concern.

    The Web Application is in Bad State, What Next?

    You've just opened a can of worms, so this is a hard question to answer. But there are a lot of things to consider. Consider what legal consequences can occur. Consider what impact it will have on customer experience. Consider how costly it is to address these issues. And worse case scenario, consider changing the technology. You will have to work with your solution provider to determine the most relevant approach to your situation.