Website security is multi-faceted in that it encompasses the provider's network center, server operating system, web hosting environment, httpd software, as well as the platform used to create the website. Each aspect has a set of security considerations and expertise.
Website security is also multi-layered as every component needs to be protected, updated, and evaluated -- periodically. If the hosting company is effective in handling the security considerations of the hardware, server, and network then developers can restrict their focus to the web hosting environment.
The security barrier is defined by the type of hosting plan used for the website. A shared hosting plan restricts the attack surface that can be dealt with to the hosting environment. At the other end are dedicated servers which expands the security responsibility to all aspects of the server. The hosting company will typically provide
DDOS , throttling, and other protection mechanisms regardless of hosting plan.
Misconception: My website is secure as it has an SSL Cert An SSL Cert only protects connections to the website for those web clients that are using it. There are techniques that avoid using a https connection, or use a deprecated standard (TLS 1.1). There are also methods to force secure connections. SSL Certs only protect connections and do NOT protect a website.
Misconception: My website application is updated. Updating the application is a good strategy as it is the client facing portion of the website, but it is far from the only component of a website that needs updating. Many modern, well-built content management systems and applications rely on other software applications to reduce their codebase and standardize activities, such as content consumption from API s, sending email as well as tens-of-thousands of other possible functions.
Each of those libraries may in-turn depend on other libraries. So, far an application to be truly updated, each and every library that directly or indirectly support its functionality need to be updated also. Composer , npm , and other technologies exist to automate that in modern applications .
Drupal is a great platform built for Composer updates and install. At this time, MODX3 does not implement it as well and even bloats its size due to having vendor files preinstalled in the download file rather than having them downloaded via Composer during the installation. In our opinion and over thirty years experience, WordPress is the absolute worse kludged technology that should NEVER be used on any project.
Misconception: Antivirus scans are run on my website. Most antivirus software operates in two realms: on the physical files and in the memory. The problem with websites is that technologies exist that can create and inject a virus on the fly, thereby possibly bypassing any antivirus scan.
Misconception: My site is PCI-DSS compliant. The purpose of PCI-DSS is to protect credit card credentials. The best technique we have found to be PCI-DSS compliant is to outsource the entire payment process to a third-party: Authorize.net, Square, Stripe, etc.
It is very easy to be non-compliant, just collect the shipping information. More often than not, that information duplicates the credit card Zipcode, address, and name.
As a developer using the leading payment gateway, I was appalled at the number of developers sending portions or the entire credit card through insecure email to the website owner or store the entire transaction in the database. How do we know this was going on? Those developers were publicly asking for assistance to conduct these activities or sharing their order-fulfillment process which included non-compliant activities.
We built an entire cellular company and the only part of the credit card information we received was a client token and a status (success or fail). We could even use the token to pay out commissions WITHOUT ever having access to their account information.
In the future, new payment technologies may very well bypass any need of PCI-DSS compliance.
Misconception: My site is HIPAA-compliant. Is it? How do you know? Have you read HIPAA? Do you collect any information from your website visitors? Is every aspect of their information encrypted from the point of collection to its storage? Can any staff member access the patient data? Have you built a mechanism that allows only the intended healthcare professional(s) to view it? Can your content management system actually limit content to specific users or subgroups?
We have audited source code and medical offices and found very few of them are actually HIPAA-compliant. We have found their data collected and stored unencrypted. Only their backups were encrypted. Access is typically staff-wide. Even worse, the widely-used client management software used was not functionally HIPPA-compliant. In some instances, while under NDA, we were able to convert their data to an actual HIPPA-compliant solution.
Misconception: My website protects visitor information. Does your content management system separate login credentials from user information? Is user data, e.g., contact information, optional? Do your applications separate user interaction from user data?
Every application we build, is website visitor nescient. In other words, the application has no methodology to understand which user is connected to which data, while the primary identifier of the user authentication is loosely connected to the application to restrict access to the data to the authenticated website visitor.
For the most part, applications are not in need of user personal information to perform their tasks. Any application that does interact with personal information should be very obvious in doing so - like surveys, opt-ins, account related information, etc.
Misconception: My website is secured on the server. Unsavory web hosts exist. Poor configurations can also occur. Some web hosts do not "jail" users to their own directory prohibiting them from traversing other websites on the server at the directory level allowing full unintended direct access similar to files on a home computer.
FTP and telnet should be disabled to keep plain-text passwords from being transmitted and possibly intercepted as they may be the same used to log into a control panel gaining access to email accounts, files, dns records. Some of these actions could allow a website or email to be hijacked, redirected, and spoofed.
Other attacks on a webserver can transpire due to poorly configured memory settings. Global variables could be accessible by other websites if the memory space is shared between them. This might expose database credentials, api signatures, etc.