Security is important and most times an after thought. One only needs to look at the debacle of Neiman Marcus or Target just recently to see why security should matter at the code level for web developers. As a side note, these companies are in good (or bad) company and many have been victimized. The reasons for the attacks or hacks may be different, but here I want to cover the basics to protect your website and your clients’ websites.
The following are 3 Tips that will make the likelihood of being a victim very small, though not impossible. If a hacker is determined and has funds to support the effort the hacker possibly will penetrate. The point here is to not be the slowest sheep in the herd leaving you open to a predator.
1. View everything through security colored glasses: Securing the code goes beyond best practices like having the appropriate write permissions on directories. Within the code websites should function in a way that is less vulnerable i.e. like giving away less info to fight vulnerability sniffing. Your website should be developed by folks that understand the risks associated with online work. Everything starts with knowing there is a problem – a perpetual security problem.
- Horror story: I have a client that is a social figure and was targeted for hacking. We’ll call the client Bill. Bill had enemies in nation states that not only did not like him, but hated Bill’s country of origin. The hackers looked for the vulnerabilities they could leverage without much effort. So in other words, they found the lowest hanging [security] fruit. They found it and attacked it over and over. The previous company of record did not secure the server and it was a security nightmare that I fixed with the help of others in weeks.
2. Secure the Transaction Funnel: You would think this is a no brainer. But even at the smallest level (let’s say a small e-commerce) selling e-books can miss the mark. Just because you are only using PayPal doesn’t mean you should not employ SSL to stop users from losing there data during an attack. Some may say a small site shouldn’t worry. Everyone should worry. PCI compliance should be required for commerce and if your org can’t reach that level of security then you should differ that to an org like Stripe.com that can and lessen risk to the client.
- Horror Story: Let’s call this client Jane. Jane invested more than 25k on an e-commerce website. The developer writing the code wrote a back door into the website where he could conveniently trap the transaction and copy that info to himself. I not only couldn’t help at this point, but I told her that the website was void and irrevocably insecure. That’s a nightmare. The developer was in another country and the client lost all her money.
3. Secure the Client Data: Bad password protocol for WordPress sites, ftp, root, as examples are still terribly open to attack. You think things would change, but people are lazy. Hackers at times with certain types of attacks are betting your password is just “password”. If a company can’t take the time to create very large hash like passwords for clients then they are creating needless risk. Not taking time to deploy long hash passwords is the norm. Other security goals includes, all client communications should being encrypted at least on a basic level. All drives should be encrypted with call home functionality. All client files should be redundant, versioned, and locked away offline.
Taking the time to do these 3 simple steps will totally help you close security gaps. Security cannot be an after thought, you must take the time to consider security from day 1. Above all, keep your code in the US and under US law.
The web isn’t the “World Wide Web”, it’s the wild wild west so giddy up security cowboy.