Can a C or C++ web app have XSS, and how do you stop it?

Yes. Cross-site scripting is about the HTML a program sends, not the language that produced it. A C or C++ service that writes user data into a page, an error message or a JSON response can be vulnerable. Many such services have no framework doing escaping, so you must encode by context yourself.

Why is this different from web frameworks?

OWASP observes that applications built on modern web frameworks have fewer XSS bugs because the frameworks use templating and auto-escaping. A C++ embedded device web server, a CGI binary or a hand-built HTTP service often has none of that. Output is assembled with string concatenation or formatted printing, and nothing marks which pieces are trusted.

OWASP's defense philosophy applies without change. All variables need to go through validation and then be escaped or sanitized, and any variable that does not is a potential weakness. In a language without a safe-by-default template layer, that discipline has to be built into your own output functions.

A constructed example: a router admin page, written in C, shows the device name in a status banner using snprintf into a buffer that is written to the socket. The name is user-editable. Entering markup as the name makes every admin who opens the status page run the attacker's script. The memory handling is correct. The bug is entirely in the missing encoding.

What are the contexts you must encode for?

OWASP lists a separate encoding for each place a value can land.

1. HTML body: use HTML entity encoding, which turns the ampersand, less-than, greater-than, double quote and single quote into entities.
2. Quoted attribute values: use attribute encoding, always keep the quotes, and keep attribute names fixed.
3. JavaScript: use an encoder documented for the exact spot, and never insert untrusted code or identifiers.
4. CSS: place variables only in property values.
5. URLs: percent-encode query values, then attribute-encode the whole URL if it goes into an attribute.

OWASP warns that using the wrong method can introduce weaknesses or break the application. Write one function per context and name it for the context, so a reviewer can see at a glance that a call places a value correctly.

Where do the leaks usually hide?

Look beyond the obvious page template. Error pages that echo a request path, debug endpoints, redirect pages, JSON responses served with an HTML content type, and logging views for administrators all emit data. OWASP says that for JSON you should verify the content type header is application/json and not text/html.

Cases where encoding is not enough also exist. OWASP names dangerous contexts, such as placing variables in places where script can be introduced, and says output encoding is not perfect. When the product must allow markup, sanitize with a maintained HTML sanitizer or avoid the feature.

What to do

1. Inventory every function that writes to an HTTP response. Mark which ones receive data from requests, files, databases or devices.
2. Wrap output in a small set of context-specific encoders and ban direct formatting of untrusted values into responses.
3. Set explicit content types and the X-Content-Type-Options header so browsers do not guess.
4. Add a content security policy that blocks inline script where the application allows it.
5. Test with a short list of markup payloads in every field, in a staging build. Include fields that appear only on admin pages.
6. Review third-party code. Lists of components should be tracked, and Safeguard's SBOM and dependency scanning can show which libraries in a native build carry known issues.
7. Fuzz or unit test the encoders themselves, including multibyte input and truncated buffers, since encoders in C must also avoid memory errors.

Quick check

Sources

1. OWASP Cross Site Scripting Prevention Cheat Sheet

Last reviewed: 18 October 2026.