Website security: what does it mean, and why you shouldn’t underestimate it?

Done! Another great website is ready to be released, and behind the elegance of an intuitive and simple user interface, of an efficient and accurate graphic layout are hidden thousands of HTML lines, blocks of Javascript code with innovative features containing AJAX, jQuery, maybe mixed with a little bit of REST – and again, on the server’s side, other hundreds or thousands of PHP lines, and SQL tables.

Between you, your website and the right compensation which will render feasible the longed for summer vacations, is the client and the approval of the website. The client who maybe is not a complete stranger to IT as he tries to pretend, or maybe it is like that but knows on who to rely on regarding decisions within the sector… the demonstration of the website goes on smoothly, until the fateful question, a variation of any kind on the topic:

“But is the website secure?”

Are you able to give an answer that leaves you calm on the beach, and your client, too being caught up with his new investment?

In this article I will try to provide not only motivated answers, but also make sure that these answers are sincere and satisfy the security requisites of a website. The security issue, in reality, is way ampler, and covers in a uniform manner everything that has to do with our data both in terms of bad-intentioned damages and those caused by software or hardware failure or even catastrophic events, but here we will concentrate above all on the security of the Rich Internet Application and dynamic website (for convenience I will refer to everything simply as ‘website’ – many sites nowadays have complexities even superior to classic RIAs) and how to render more solid the websites based on  Javascript, jQuery, JSON, Apache, PHP and SQL. Therefore, about how to make it not only to go on vacation, but also to enjoy them without risking to receive under the sun the classic:

“But there are indecent pictures in home page!”

Basic concepts

First of all, we empty the field of question number 1. Is it possible to have a 100% secure website?

The answer is the first law of security: no, it’s not possible. I can have a 100% secure website now, but later on it won’t be, either because some genius in any corner of the world will discover a new method for breaching the security of the web server, or because a trojan in the client’s structure will open a path through which some hacker will steal, among other files, also the password of the website’s back office which some distracted employee has saved in a text file on the desktop. Or even, simply read on the post-it attached on the keyboard of the same employee. Distracted, or even miscreant: never exclude anything or anyone.

The first concept is clear: the security of your website is a very, very long chain, which contains only in part your work, but also structures and personnel:

  • the user’s side, that is what the navigator loads: HTML, CSS, Javascript, inside the browser which uses (Firefox, IE, Chrome, etc) and of the operating system (Windows, OS/X, etc);
  • the internet network, with all the gathering points, the gateways, that is where our HTTP requests travel to;
  • the web farm, where our website resides physically, all the PHP files, all the databases;
  • the client’s side: if the application has a back office which allows our client to manage the database, or write the texts, or download images … this also becomes a link of our chain.

Wherever a machine for accessing the network exists, there is the possibility for a technological attack, based on the network security which leaves to be desired, new and old software bugs and never correct (a very common case nowadays, where budget cuts hit with no mercy even the same foundations of any IT department), possible hardware intrusions.

Wherever personnel exists, it doesn’t matter if executives, employees or service staff, you have a potential point of social attack, based on phishing, or through random human relations which allows for the seizure of passwords, at times very classified ones … simply by asking them over the phone. Or after taking a peek behind the photo on the work desk, or under the mouse, or written on the label of the LCD monitor, or easily deducible …

The integrity of the chain is compromised even when only one of its links is compromised. From here we obtain the second law of security:

the security of the entire chain is equal to the security of the weakest link.

Thus: the chain can be attacked in all of its points and in all possible manners, both technological and social, with various degrees of resistance to the attack. Some are absolutely unpredictable and inevitable, or impracticable, which means that a website will never be 100% secure! And as a web developer, there’s not a lot you can do for a good part of these problems.

But this does not mean that you have to stay with your arms crossed: on the contrary! You have three tasks:

  1. create a website which doesn’t lend a hand to technological attacks – we are going to talk about this later on, and in depth even;
  2. involve the client with the problem, make sure they understand s0cial attacks and know how to manage them: if our application generates or makes use of passwords, do not make a compromise on the quality of passwords: ‘equal for all’ passwords are not acceptable (besides, for the protection of privacy discourse, it’s even illegal)! That they are made aware of the risks their data face: it would be like all similar cars had the same key;
  3. prepare the necessary resources and instruments in case the worst would happen: copies of the website in the various versions, backups, configurations, forensic tools and materials – even this is going to be a topic for discussion. And prepare also the explanations to provide the client with, when necessary.

And if you don’t do that? Apart the risk, almost certain, to lose a client maybe even important in case of problems, you might also be sued, you might not be able to show that you did your best – because your website might be used as a Trojan horse to get access to more critical and restricted areas, and all this maybe just for a banal

$h = popen("zip -r 9 $file",  "r");

mishandling inside of one of our phps.

How to talk to the client?

It is absolutely necessary to keep a sincere relation with the client since the very beginning, but at the same time provide strong arguments. The idea that a website cannot be 100% secure is scary – but the same thing applies to a store, a vehicle left in a parking lot, an appartment, even more if we are talking about banks, luxury automobiles and villas – in direct proportion. Nobody renounces to buy a car only because there is the risk it might be stolen: in that case, you take care of securing the keys, parking it in a safe place and insuring it!

Same as with the anti-theft device at home which discourages and chases away, but doesn’t provide absolute security, the same way security on the web discourages and chases away – and unlike, alas, with the money stored in the bank, we can eventually make extremely secure backups to allow us, at least, to restore fast what was damaged. On this, the client has to be assured.

In most cases, the client will understand and will be ready to take part in the management of security. In other cases will be less understanding, and the issues he will raise will revolve on these topics:

  • “It has never happened to me!”
  • “Nobody knows us – it is an unknown url!”
  • “There’s nothing of real value on this website!”
  • “We cannot remember all these weird passwords!”

Topics we have to know how to confront by demonstrating to know the answers:

  • because it never happened, it doesn’t mean it won’t happen! Whenever the risk is underestimated, that’s when the most damage is caused;
  • links are spread rapidly, it doesn’t matter who you are: big or small, you are always interesting for the simple fact of having a space on the web which can be used for other scopes. On the contrary: if you are small, you are interesting because you are less ‘powerful’ than the big names, which can afford to unleash armies of lawyers;
  • the web space, client details, your image and brand are elements of value – you can imagine what an effect it would have if next to your name appeared material, so as to say, at high resolution and colorful in content?
  • passwords are equivalent to keys – the complexity, as well as the frequency we change them that’s what keeps them secure.

In the next article, we will start to examine the complete structure of a website through all its parts, as if it were a house and we had to value its security observing windows, doors, door locks, walls, letter carriers and meter reading controllers.

But before then, let’s talk …

In your projects, how’s that you have dealt with the security issue in front of your clients? Have you ever had to manage emergency situations?


  • Choose the theme or the plugin that most suits to your online business
  • Download and install it freely with few clicks
  • When you will be positive about your choice, enjoy the advanced features
Your Inspiration Themes >
[pdf]Scarica articolo in PDF[/pdf]
Tags: , ,

The Author

Cristian is a freelance computer, specialized in the design and production of websites and, more generally, technology and Internet related mischief.

Author's web site | Other articles written by

Related Posts

You may be interested in the following articles:


Trackback e pingback

  1. Tweets that mention Website security: what does it mean, and why you shouldn’t underestimate it? | Your Inspiration Web --
    [...] This post was mentioned on Twitter by Tom Bangham, V. Tavares (E-Goi). V. Tavares (E-Goi) said: Website security: what …
  2. Security and Web sites: Code Injection | Your Inspiration Web
    [...] Website security: what does it mean, and why you shouldn’t underestimate it? [...]
  3. Security and web sites: how to find the causes of code injection attacks, validation techniques | Your Inspiration Web
    [...] Website security: what does it mean, and why you shouldn’t underestimate it? [...]

Leave a Reply