What is XSS and how to prevent code from executing on your website?
Published on 2026-10-20 by frfrand
Cross-Site Scripting explicado: diferencias entre texto y código, casos en comentarios y formularios, escape por contexto y sanitización segura.
XSS means Cross-Site Scripting and describes a family of vulnerabilities in which untrusted content ends up being interpreted as active code within a web page. In many cases the origin is data entered by a person: a comment, a biography, a product name, or a URL parameter.
The problem is not allowing someone to write text. The problem appears when the application treats that text as if it were part of the instructions the browser must execute.
The example of a comments section
Imagine a website where users can publish reviews. Each review should be displayed as text, even if it contains strange characters, quotes, or code fragments.
If the system inserts that content into HTML without proper treatment, the browser may interpret it as markup or execute instructions that do not belong to the site.
This may allow unwanted actions in the context of the page, access to certain data available to scripts, or manipulation of the content the visitor sees. The impact depends on permissions, architecture, and existing protections.
Why blocking the word "script" is not enough?
Because browsers interpret HTML, attributes, JavaScript, URLs, and CSS in different ways. An improvised list of forbidden words does not cover all contexts.
The correct defense depends on where the data is being placed. Displaying text between HTML tags does not require exactly the same treatment as using a value within a URL or an attribute.
That is why OWASP recommends context-aware output encoding and, when HTML really needs to be accepted, sanitization using appropriate tools.
What is escaping content?
Escaping means representing certain characters as data so that they are not interpreted as active syntax in that context.
An easy example: if you want to display <b>Hola</b> literally as text, it should not be transformed into an active HTML tag. A framework can convert it into visible text or use appropriate entities.
Many modern UI libraries apply protections by default when inserting values as text. But there are special functions for inserting HTML without that treatment; using them with untrusted content increases the risk.
Do React and other frameworks avoid XSS automatically?
They help a lot when you use the safe functions, but they do not eliminate any possibility.
For example, React usually escapes normally interpolated text. However, there are mechanisms to insert HTML deliberately. If you feed those mechanisms with untrusted content without sanitizing it, you can reintroduce the problem.
URLs, external libraries, versions, and components that convert data into code in special ways also matter.
What if I need to allow rich text?
In a blog or editor, it may be reasonable to allow titles, links, and bold text. In that case, you cannot show absolutely everything as plain text, but it is also not advisable to accept arbitrary HTML.
The alternative is usually to use a limited format and a maintained sanitization library, with a controlled list of allowed elements and attributes. Additionally, it is important not to modify the sanitized HTML afterwards in a way that makes it unsafe again.
Does a CSP policy solve it?
Content Security Policy can reduce certain risks by limiting where scripts are loaded from and what can be executed. But it should not be the only defense.
A WAF does not replace a secure implementation either. Some XSS attacks occur entirely within the browser logic and do not necessarily go through a server request filter.
Three common mistakes
Trusting what comes from the database. Just because data is stored does not mean it is safe: perhaps another user introduced it a month ago.
Escaping in the wrong place. A method suitable for HTML text may not be enough for a URL or a JavaScript context.
Allowing HTML for convenience. If you only need text, show it as text. Reducing dangerous functions makes security much easier.
How does it relate to ArduMaker?
An application deployed on an ArduMaker VPS can be perfectly configured regarding ports and HTTPS and, still, present XSS if its frontend misinterprets external content. Prevention is worked mainly in the code and in the way data is represented.
In summary: XSS appears when untrusted content stops being treated as data and becomes active code. The central defenses are safe output, contextual encoding, and sanitization when necessary.
Source: OWASP XSS Prevention Guide · Content Security in MDN.