We have an OpenCart 2.3 hosted in Amazon Web Services. We have taken steps to protect against XSS, i.e. we activated XSS protection on AWS set-up. On Google Chrome, you will see our header:
X-XSS-Protection:1; mode=block
One test I did was to enter the following on the checkout comment:
<html>
<script>Alert('hello world')</script>
</html>
On checkout, no alert was displayed, meaning the script did not execute? I checked the database and saw that the tags were encoded, e.g is stored as <html> This should mean that our site is protected against XSS?
What other steps can we take to fully protect against XSS
The
X-XSS-Protectionheader doesn't do what you think it does. See What is the http-header "X-XSS-Protection" for a nice SO overview of it. But the tl;dr is that it enables some behaviour on IE8+.Speaking more broadly, XSS, by it's nature, isn't something you can protect against with a single action. Every time you take in some user input, you have to be extra careful to validate that it respects the format you want it to be in. Whenever you present that input to a user, you have to properly handle it, so that a malicious script doesn't execute in the context of that user, and does bad things.
The OWASP has a nice XSS prevention cheatsheet which is a very nice resource.
But, in principle, always escape the user-supplied input according to the area where it is going to be displayed. If, for example, a user has supplied some text for the title of a shopping item, then that should be just text, and used in an HTML element that expects just text (one of the inline elements for example), and HTML-escaped etc. On the other hand, if a user has supplied an URL, then that should be used in a context where an URL is valid (as the source of an image, for example), and URL-escaped. Avoid allowing users to supply their own HTML, CSS or scripts. And avoid putting user-supplied values in scripts, CSS etc.
Finally, since you're using OpenCart, you're benefiting from loads of work other people have done already. So, unless you're doing something extra-custom and playing around with the inner bits of the framework, you're probably not going to run into deep waters. And follow the conventions inside the framework, of course.