It’s understood that security is not an endpoint. It is a process that requires constant vigilance, reassessment and evolutionary change.
The security of a website is no exception. Most websites continue to have security vulnerabilities because the primary focus tends to be on application functionality and not security. Application developers are incented to finish updates quickly and often don’t understand the security risks the changes may have introduced.
There are two separate responsibilities to addressing website security that enterprises need to embrace: First, you need to find the problems; second, you need to resolve them. It certainly sounds obvious but it often turns out to be more complicated than anticipated.
Too often, companies treat website testing like it is a onetime event instead of having it be part of a security program. Websites need periodic (in most cases, at least yearly) independent vulnerability assessments. Also, if there has been a major change in the application or backend servers and services, or the webserver or host, the website has to be checked again for vulnerabilities.
After the assessment is performed, it is quite likely there will be vulnerabilities that need to be addressed by the group that manages the host it runs on (e.g., open ports and services), the people who configure the webserver it runs on (e.g., SSL certificates, supported HTTP methods) and the application developers (e.g., XSS, injections, input validation, file upload, clickjacking, CSRF). In other words, improving website security usually requires assistance and coordination from many different groups.
The companies that are successful in minimizing website security risks have instituted an ongoing independent security testing program that identifies risks and have established clear responsibilities for remediating the issues that are discovered.