All recent versions of Mendix (from 3 up) are protected against commonly known XSS techniques. You can let security companies perform tests to check.
On any input field on a form you can add validation, although it will be client-side validation.
You can do server-side validation of data by adding Validation Rules (see Properties of the entity in the Domain Model). These rules can verify uniqueness, that an attribute falls within a range, or matches a regular expression.
That being said, XSS is used to inject scripts on your browser and html pages, so client-side measures are very helpful as well.
Hopefully, someone from Mendix can respond about any vulnerabilities there might be, or any other best practices.
If you allow users anywhere to enter some form of HTML / richtext data (this holds for the rich text editor as well!) you should always sanitize your input to remove any malicious HTML / javascript code. The community commons module provides some default java actions to do so.
According to an answer above, Mendix is protected against commonly known XSS techniques. The XSS Sanitize java action from the CommunityCommons, removes XSS from a string.
For example:, according to https://www.owasp.org/index.php/Cross-siteScripting(XSS) can be seen as XSS, and the XSS Sanitize action cleans this. However, I can store this string without any problems from a Mendix form.
So, do we really need to validate each string attribute on XSS before commit? And what is the Mendix platform exactly providing agains XSS attacks?
According to an answer above, Mendix is protected against commonly known XSS techniques. The XSS Sanitize java action from the CommunityCommons, removes XSS from a string. However, I can store a string, containing XSS without any problems using a Mendix form.
So, do we really need to validate each string attribute on XSS before commit? And what is the Mendix platform exactly providing agains XSS attacks?