Top Five Website Security Myths

Jason ParmsCustomer Service Manager
Security has become the most important factor to be considered for websites, especially for e-commerce websites.

Just securing your website is not enough. You need to keep a watch for vulnerabilities on your website; also you should keep updating your security systems in order to prevent yourself from being a victim of cybercrime.

Installing an SSL certificate may prevent your website from being hacked. Having the firewall option enabled does not guarantee the authenticity of the website.

There are several myths prevailing regarding the security of the website that, if not corrected, may result in a great loss.

Let us have a brief look over some of the myths of the website security.

Myth Number 1: Developer is responsible for security flaws

Fact: Your developer is not responsible for an unsecured website. The source code of a website is either built within the organization or it can be developed from outside. Sometimes code available on the other websites is used as an integral part of the existing code. Generally, due to the shortage of time, developers have to depend on the ready-made code available offshore.

In these cases, one cannot assure the proper authenticity of the code.  What we need to do is to encourage the developers to build the source code that is unique at the same time, safe.

Reviewing the code at regular intervals is a must for assuring the security at the source code’s end.

Myth Number 2: Firewall checks for the security of the website

Fact: A firewall guards the traffic coming to your website. It does not ensure the security of the website contents (like code vulnerabilities, business logic vulnerability etc.) thoroughly. A firewall consists of a list called the Access Control List (ACL), based on which the firewall allows a particular website to be accessed.

ACLs, which are configured securely, deny the traffic from entering into a network until and unless they have permission to do so, such as for E-mail. Only port 80, dealing with HTTP traffic and port 443, dealing with SSL traffic will be opened after scanning a website. All other traffic is blocked by the firewall.

The firewall does protect the website from the known vulnerabilities, but it cannot protect the website from the unknown threat. It temporarily cures the website during the vulnerability but does not give permanent relief from it.

Myth Number 3: My SSL is broken, therefore; My Certificate Authority is also untrustworthy.

In fact, certificate authorities focus on providing robust and global standard security to customers. CAs always try to bring scalable enhancement to the current algorithm system or try to replace the system with new one.

Second, CAs issue many types of SSL certificates depending on the business types, ranging from code signing certificate to extended validation certificate. Each CA has to follow standards implemented by the CA/B forum (Certificate authority/Browser forum) which is a standards body. Browsers like Chrome and Firefox also have to implement these standards as well.

Third, CAs are closely regulated by third party audits. If any CA does not follow the guidelines of third party audits, they can be excluded from the root store maintained by browser companies. Browsers will not trust excluded CA certificates and will show an invalid SSL error. Therefore, many CAs work with browser companies to make web security better through collaborative research and practical measures.

Myth Number 4: Vulnerability scanners will secure my website

Fact: Most of us really believe that website scanners will preserve the integrity of the website. Vulnerability or malware or other such scanners scan the website and report any issues. After resolving those issues we feel we are safe enough to trust the vulnerability scanners. In reality, website scanners do not display the security issues residing in the custom web applications. Most of the time, there is a security breach in a web application layer like in custom applications or web code. The vulnerability scanners never highlight such issues.

Web site scanners do not contain the information about new vulnerabilities in their database. Hence, it is not wise at all to rely on the vulnerability scanners for security of the website.

Other myths prevalent regarding the website security are:
  • Why would someone hack my website?
Be it a small or large, every website is at equal risk. We do not know the intentions of the intruders intercepting our website. They may use your website as a medium for spreading malware or viruses to your visitors. They can steal sensitive data that resides on your server.
  • I am not using Microsoft and other such OS so my website is safe.
Operating systems like UNIX, Mac, etc. need to have patches and updates applied if the website is hosted on them. Many popular Content Management Systems (CMS) hosted on operating systems other than Windows stay at high risk of being targeted by hackers. Security breaches such as phishing, cross-site scripting (XSS), business logic are not at all dependent on the OS.
  • Having a backup makes us safe.
Backup is a recovery help and not a safety mechanism. It is not necessary that they contain all the transactions up to date. In addition, if your live data is corrupted, then your backup also becomes void.

Myth Number 5: Routine Annual assessments will secure my website 

Fact: Any website, be it a commercial or non-commercial undergoes a lot of changes during its lifetime. These changes provide a medium to the incoming vulnerability. Hence security assessment of a website is a must once in a year. Many times updating a website in a hurry causes many security loopholes.

An ongoing website is likely to become the victim of security flaws as it needs to be updated in a short span of time; it cannot afford to be unavailable not even for a day. In these cases, any changes done on the website are not properly checked for security. To avoid such consequences, test each scrap of the website on a regular basis; enable the logging and alerting functionalities as that will reflect the changes made in the file if any.
Jason ParmsCustomer Service Manager

Comments (0)

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.