Let’s say you’re a web designer on the development team of a brand-new website. The objectives of this new site are clear, and the word handed down from above places importance on three areas. One, the site has to be visually appealing. Two, the site needs to be easy to use and intuitive. Lastly, the website needs to be secure.
If you’re a savvy developer who really knows their stuff, you know that the security aspect should be first. It most certainly shouldn’t be pushed aside at some point in the process to clear the way for some aspect of the above-mentioned points one or two that the company wants to implement. At no stage of the development should security be compromised. But you also know that can and does happen.
If you’re a security consultant who has been brought in to be part of the team developing a website, there’s a good chance you’ve faced something like this yourself. And to some extent it’s understandable. It’s the visual aspect of a website that becomes of the utmost importance, pushing aside those unseen measures behind the scenes. And then there is conflict on the team because goals have begun to differ.
You may not know it, but a lot of the things that bring visual appeal to a website, a lot of the bells and whistles, are the very things that have the potential of being a security risk. Reams of JavaScript code are written, with hours of time spent on it, ensuring the desired visual result, but at the cost of security control testing. You’ll often hear things like, “Well, some other website is getting away with it, so why can’t we?”
What Can Be Done?
You may not have faced such a situation previously, but in case you do come up against it in the future, there are some things you can do. Do to ensure that your goal of security remains on the priority list.
One of the first and simplest things you can do insists on the use of a VPN. However, you have to convince the team to do so, perhaps by looking at reviews of VPNs, or getting specific and looking at VPNpro’s review, get everyone on board so that you at least implement this first line of defence.
Once you get past that, recognize the first stage is acceptance. Realize that as crunch time approaches, no matter what promises and reassurances you have been given in the past, security concerns quickly become less of a priority. While the pure design and visual aspects of the website — the look & feel — quickly dominate any discussions the team has regarding issues.
Your best bet is to implement business logic early in the process. Take the time with the team to discuss and identify any component of the process that has the potential to introduce a variety of vulnerabilities.
An example of how you can do this would be if you were building a website that offers a subscription service to a magazine. Run a test by starting and building the complete process from registration onward. While running tests, you will be able to uncover any issues that arise, as issues do, no matter how in-depth your planning is. Doing this will ensure you have no surprises when the website is live. Nothing is going to look pretty at this stage, but that doesn’t really matter. The objective here is to simply run tests and ensure the integrity of security measures in place. Doing this could potentially save you from a disastrous situation.
Another alternative is to split up application development, so the tasks are handled independently, and all the data is separated from the view. The data will be unformatted and display neutral. This means that the code doesn’t need to be rewritten. It’s written once, allowing the graphic team to concentrate on the view. Ultimately, each team is working with each other instead of against each other and potentially holding up the project.
Factor in a Cushion
A final thing to do would be to allow yourself at least two weeks time as a cushion. Meaning that your completion date and your launch date should be a minimum of two weeks apart. This will give you time to run further tests to make sure all security measures you’ve implemented will stand up against any stress tests. If you do discover issues you’ve still got enough time before your launch date to be able to address them and make whatever corrections to the code are necessary.
Achieving a secure website is not going to be easy, but with the right amount of advance planning, and teams that are willing to adjust and work together should ultimately provide you with a website that’s not only beautiful in design but safe and secure.
