Common myths of application security
Everything in life has commonly accepted ‘facts’ that we all think are true but that when we dig a little deeper turn out not to be after all.
Needless to say the world of application security is no different.
However, believing in them could spell disaster for your business or organisation so we’ve listed some of the big ones we’ve heard together with an explanation of why they aren’t true and what you can do to make sure you don’t fall foul of them.
SSL (Secure Socket Layering), when implemented properly, ensures that any data transferred between a website and a user’s web browser is encrypted (and so can’t easily be read by anyone else) and confirms that the user is connected to the correct server and is not an imposter but has no effect on the security of code of the website itself.
A good analogy for this is that it’s like using a security company to send and receive post to and from your business and customers. This is a very secure way to communicate but doesn’t help protect their data from being stolen in other ways if you leave your doors and windows open at night.
Google indexes everything online unless you physically take steps to stop it doing so. If Google can index it then people using Google Search can find it even if the data in question is on page 10,000 of a standard search.
You could compare this to having a house in a really remote part of the countryside, stuffing it full of valuables and then not locking the door as “No one ever walks past” even though its location is actually clearly listed on a map and so burglars can easily find it, if that’s the sort of thing they specialise in.
Whilst it is true some hackers do set out to target specific types of sites, many simply use automated software to trawl the internet to look for sites that are vulnerable to hacking and then attack them sometimes without even knowing who you are.
Here a good analogy is that many burglars typically walk around looking for a place where they can easily steal from rather than heading for a specific property. See our handy video guide that explains this more here:
The security (or lack thereof) of a website or web application is only as good as the way that it has been built not what it was built with.
It’s perfectly possible to take something that is inherently secure in its design and set it up in a way that completely negates all its strengths! As such it’s always really important to check how something has been built not just accept that what it was built with will ensure good security.
Think of this as like having a house that uses the world’s most secure doors and windows but they are either held in place by sticky-tape or the builder forgot to add locks to them so they can easily be got around despite their individual strength.
Whether open source or enterprise no one sets out to build insecure software so most applications typically start out as secure and so long as they are monitored and regularly updated they usually stay that way.
Where open source software sometimes develops a bad reputation is that it is often used by people who don’t update as frequently as they should and they gets hacked as a result. The fact that this happens is very public as it’s open source (the reality is the enterprise/proprietary software often suffers the same problems but they aren’t publicised in the same way).
Testing for QA (Quality Assurance) usually focuses on whether a website or application looks and functions the way it was expected to when it was designed for use in normal circumstances. What it doesn’t generally check for is what happens when people do things that aren’t expected, such as trying to hack it as the process is very different.
A good analogy is that it’s like checking that a building contractor has done their job properly by looking at the quality of the finish, that the doors and windows close and lock but not checking that the locks used can’t be opened by a specialist without a key or that someone experienced couldn’t sneak through a bathroom window if they really put their mind to it.
Websites and applications are almost always available on the internet long before they go live in the form of staging, testing and client approval sites and if they are on the Internet there’s a very good chance that Google will find them – see our Google myth above.
This means that security needs to be planned and built in from the outset to ensure that hackers don’t already know too much on the day a website goes live as a result of having already compromised earlier versions they’ve found.
The sad reality of application security is that it is an ever-evolving field and so what is secure today may not be tomorrow and almost certainly won’t be in a few months’ time.
Once a website/application is launched it is immediately placed into a world where everything it uses – servers, the software used to build it, third party components, the way it’s being maintained and updated, EVERYTHING! – is constantly being probed for weaknesses and, when one is found, exploited.
Staying secure means keeping up with the changes in the world around it and regularly checking that the website/application has been properly updated and that no one working on it is doing anything that may compromise its security too.
We’re technology neutral so have nothing against Macs but this is a recurring myth we hear on an almost daily basis so we had to include it needless to say.
Compromised computers and other devices like smart phones often give attackers access to personal data and to the company network, servers or websites that the device connects to allowing them to hack them too.
In this day and age anything that doesn’t have good anti-virus software installed, isn’t updated regularly and doesn’t have a user that takes some care whilst online is vulnerable to being hacked whoever makes it!
Related content you may find useful
If you happen across a piece of information relating to application security and you aren’t sure of its probity, get in touch and we will help you to sort fact from fiction.
Whether you have a specific requirement, a question you'd like answered or would just like an informal chat, contact us.Contact us today