# XSS Protection: Who Is Responsible?

DevFeed: [XSS Protection: Who Is Responsible?](<https://devfeed.tech/articles/xss-protection-who-s-responsibility-31951.md>)

Original publisher: [Read original article](<https://tech.finn.no2011/04/08/xss-protection-whos-responsibility/>)

Author: mick

Published: 2011-04-08T07:09:39Z

Content type: opinion

Language: en

Sources: [Finn.no](<https://devfeed.tech/sources/finn-no.md>)

Topics: [XSS](<https://devfeed.tech/topics/xss.md>), [Security](<https://devfeed.tech/topics/security.md>), [Front end](<https://devfeed.tech/topics/frontend.md>), [Back end](<https://devfeed.tech/topics/backend.md>), [Databases](<https://devfeed.tech/topics/databases.md>), [web applications](<https://devfeed.tech/topics/web-applications.md>)

Tags: [backend](<https://devfeed.tech/tags/backend.md>), [cms](<https://devfeed.tech/tags/cms.md>), [cookies](<https://devfeed.tech/tags/cookies.md>), [databases](<https://devfeed.tech/tags/databases.md>), [front-end](<https://devfeed.tech/tags/front-end.md>), [legacy](<https://devfeed.tech/tags/legacy.md>), [security](<https://devfeed.tech/tags/security.md>), [xss](<https://devfeed.tech/tags/xss.md>)

## AI overview

The article examines whether XSS protection in multi-tier applications should belong to a dedicated security team or be shared across developers. It contrasts new applications, where input may be cleaned before storage, with legacy applications whose existing backend data can require extensive front-end protection, and illustrates the issue with an advertisement service and view template.

## Source excerpt

In a multi-tier application who can be responsible for XSS protection? Must security belong to a dedicated team...or can it be a shared responsibility? Today XSS protection is typically tackled by front end developers. Let's challenge the status quo. New Applications vs Legacy Applications For protection against Stored XSS many applications have the luxury of ensuring any text input from the user, or from a CMS system, is made clean and safe before being written to database. Given a clean database the only XSS protection required is around request values, for example values from url parameters, cookies, and form data. But some applications, especially legacy applications, are in a different boat. Databases typically have lots of existing data in many different formats and tables so it's often no longer feasible to focus on protecting data on its way into the system. In this situation it is the front end developers that pay the price for the poor quality of backend data and are are left to protect everything. This often results in a napalm-the-whole-forest style of xss protection where every single variable written out in the front end templates goes through some equivalent of <c:out value="${someText}"/> This makes sense but... if you don't have control is your only option to be so paranoid? A Messed up World To illustrate the problem let's create a simple example by defining the following service interface AdvertisementService{ Advertisement getAdvertisement(long id); } interface Advertisement{ /** returns plain text title */ String getTitle(); /** return description, which may contain html if isHtmlEnabled() returns true */ String getDescription(); /** indicates the description is html */ boolean isDescriptionHtml(); } The web application, having already fetched an advertisement in the control tier, somewhere would have a view template looking something like <div> <h1><c:out value="${advertisement.title}"/></h1> <p> <c:out value="${advertisement.description}" escapeXm