OWASP
Request for Clarification/Refinement: V1.1 "not stored in an encoded or escaped" Data Storage Principle
Please refer to this disucssion reference https://github.com/OWASP/ASVS/discussions/3184 , further input I am writing here as I think the current requirement may reqire some clarity and practical alignment.
Please refer the below code reference of Discourse & Ghost where they are storing encoded/sanitized data into the database, depending on architectural needs. There are lot of other popular opensource framework which are also storing the data, if needed i will share accordingly.
- Discourse : Code Reference -- Stores both raw and HTML (cooked) versions of user posts.
- Ghost : Code Reference -- Stores Sanitized/Encoded data.
Here is the brief summary of the attached link of the github discussion:
Quoting and responding to a few points raised by @elarlang in his response.
it is not possible to encode data for HTML before saving it to the database
Encoding before storage is common in edge cases and application-dependent, this totally depends on the application requirement. The above shared code example is enough to think on contradicting the absolute stance.
It ruins the integrity of the data - e.g., it was not the value that the user entered
Data Integrity: When HTML sanitization happens, the data is intentionally changed by removing malicious parts (like
It assumes that the only output encoding is HTML, but if it is to be used it in JSON, CSV, displayed as just text, or whatever other format, it is already in the incorrect format
if certain fields are guaranteed to only ever be displayed in a single, fixed context like HTML, would it be acceptable — from an ASVS perspective — to encode once during write-time?
The problem to solve here is to use the correct caching mechanism.
The encoded data should be stored into the cache, if the data should be into the cache then would like to know the reason why we are stating that "never store encoded data". Does V1.1’s “stored” include caches, or is it database-specific?
The clarity and usability of the guidance are lacking, team should consider/think the following points:
- Principles need context, blanket statements (like “never store encoded data”) can lead to confusion or overcorrection.
- Clear usecases help avoid mistakes. When developers see good and bad usecases, they better understand the reason behind a rule—and they’re more likely to apply it the right way.
- Clarify whether “stored” in the current rule applies to database only, or also includes caches.
- The “not stored in an encoded or escaped” in the statement is too absolute, as there are niche cases where storing encoded or transformed values is justified, it is good to think on Reinforce "storing raw" as the default and recommended best practice.
Quote precise text or requirement from the document that needs to be improved.
You are mixing encoding and sanitization here - they are different defence methods for different use-cases and also requires different flows when processing them.
The text below is copied from the V1.1 Encoding and Sanitization Architecture section.
They also aim to ensure that whenever data is stored, it remains in its original state and is not stored in an encoded or escaped form (e.g., HTML encoding), to prevent double encoding issues.
My concern on this " original state and is not stored in an encoded or escaped form (e.g., HTML encoding), to prevent double encoding issues."
Does the value below, which is going to be stored in primary storage, violate the above statement?
<b> OWASP < </b>
The user input value is <b> OWASP < </b>
I would like to know your thoughts on the question above.
I will ask the remaining highlighted questions one by one after this is answered.
Note: I have gone through all the requirements related to encoding and sanitization.
If user enters <b> OWASP < </b> - what is the logic behind it to be modified into <b> OWASP < </b>?
I assume there is encoding vs sanitization scenario confusion here.
I am not intentionally encoding < to < .
I’m using a popular package — the same one used by Ghost. I’ve already attached the code reference in the ticket for your review.
Please refer to the code snippet below. It automatically encodes special characters using the sanitize-html package and produces the same output I shared in my previous comment.
const sanitizeHtml = require('sanitize-html');
const html = '<b>OWASP < </b>';
console.log(sanitizeHtml(html));
// Output - <b> OWASP < </b>
The same output is produced when using DOMPurify, which is another popular package based on download stats. Please refer to the code snippet below:
import DOMPurify from 'dompurify';
const html = '<b>OWASP < </b>';
alert(DOMPurify.sanitize(html));
// Output - <b> OWASP < </b>
Please refer to the following working examples for sanitize-html and DOMPurify:
- sanitize-html (Go to Code Reference)
- dompurify (Go to Code Reference).
Would like to know your inputs.
Vol 3 - can you understand the difference between sanitization and encoding?
Yes, I do understand the difference between sanitization and encoding completely.
Well, I doubt that, as you quote encoding from the ASVS and give examples of sanitization.
For your scenario, you should look to the requirement 1.3.1.
My point is about the specific conflict that arises when this sanitized output (containing HTML entities like <) is then stored, in light of ASVS V1.1:
V1.1 Encoding and Sanitization Architecture: They also aim to ensure that whenever data is stored, it remains in its original state and is not stored in an encoded or escaped form (e.g., HTML encoding), to prevent double encoding issues.
My scenario highlights that if we comply with V1.3.1 using standard, secure tools, the resulting data will contain HTML entities (<). When this data is stored, it directly appears to contradict V1.1's explicit guidance against storing data in an "encoded or escaped form." also arise the double encoding issue (if generic or less careful output encoding is applied later).
Therefore, the critical question, which directly impacts implementation, is:
How does ASVS reconcile V1.1's general principle of 'no encoding in storage' with V1.3.1's requirement for sanitization of HTML, where the sanitization process itself includes encoding literal characters (e.g., < to <) to produce safe HTML?
Which rule takes precedence, or is there a specific interpretation of V1.1 for HTML content that allows for the storage of these specific HTML entities (e.g., < for literal <) as part of its "safe semantic original state," even though it's technically an encoded form?
In your examples, WYSIWYG or similar is in use.
In that case, the output from WYSIWYG is input for the application, the content is sanitized but never (additionally) encoded on the server side, as this is the original state to store, and this is also the exact value to use in the output.
the content is sanitized but never (additionally) encoded on the server side
The content is sanitized and (partially) encoded by the sanitizer itself on the server side. Please refer to the Ghost code reference I shared earlier — Ghost, a popular and reputable platform, directly stores HTML-entity-encoded data (e.g., < for <) in its database.
I have already shared both example server side as well as client side, the sanitize-html example is on server side and dompurify is on the client side.
Note:FYI, I have a concern regarding requirement 1.3.1, which I will address separately in another ticket.
It is still the content from WYSIWYG you store, and it is the original state for that data.
If I have not been able to explain it so far, then most likely, additional comments do not help either.
For me, there is no problem to solve in the document from this issue.
After our discussion, I’ve gained further insight from the responses shared. Below is a summary of why I believe V1.1 is currently ambiguous:
If ASVS V1.1 allows storing that data because it's considered the "original state" post-sanitization, then perhaps the rule could be clarified to reflect that. Otherwise, it reads as if storing such encoded data — even when safely produced and intended — is a violation.
The phrase "not stored in an encoded or escaped form (e.g., HTML encoding)" in V1.1 is ambiguous. It aims to prevent storing data that has been contextually encoded, but it doesn't clearly address HTML entities produced by sanitization as a necessary outcome of making HTML content safe.
The risk of double-encoding if sanitized data (with entities) is stored and then naively encoded again on output, aligning with V1.1’s concern but questioning its absolute stance.
The requirement should be simple to understand without needing extensive discussion to clarify specific edge cases, as has been necessary here. The goal of this issue is to request clarification. A simpler and more accurate version of the text might be:
Whenever data is stored, it should remain in its original state and not be stored in a context-specific encoded or escaped form (e.g., HTML-encoded for output), except where HTML entities are part of sanitized HTML content intended for direct rendering in HTML contexts.
I am open for the discussion, would like to know the thoughts of the other core/community member.
@elarlang would be great if you answer the asked question in the first comment and in this comment.
@elarlang would be great if you answer the asked question in the first comment and in this comment.
Can you point out, what is the precise question?
I am writing this message through my mobile phone, would be great if you refer The questions which are marked with a question (?).
Get Outlook for iOShttps://aka.ms/o0ukef
From: Elar Lang @.> Sent: Thursday, June 26, 2025 8:39:41 PM To: OWASP/ASVS @.> Cc: Ajay Ojha @.>; Author @.> Subject: Re: [OWASP/ASVS] Request for Clarification/Refinement: V1.1 "not stored in an encoded or escaped" Data Storage Principle (Issue #3206)
[https://avatars.githubusercontent.com/u/47597707?s=20&v=4]elarlang left a comment (OWASP/ASVS#3206)https://github.com/OWASP/ASVS/issues/3206#issuecomment-3008833439
@elarlanghttps://github.com/elarlang would be great if you answer the asked question in the first commenthttps://github.com/OWASP/ASVS/issues/3206#issue-3173926843 and in this commenthttps://github.com/OWASP/ASVS/issues/3206#issuecomment-3007707880.
Can you point out, what is the precise question?
— Reply to this email directly, view it on GitHubhttps://github.com/OWASP/ASVS/issues/3206#issuecomment-3008833439, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AE3SS3RF5QFMOEEAQSNZ7TL3FQELLAVCNFSM6AAAAACAB7TIG2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMBYHAZTGNBTHE. You are receiving this because you authored the thread.Message ID: @.***>
The problem to solve here is to use the correct caching mechanism.
The encoded data should be stored into the cache, if the data should be into the cache then would like to know the reason why we are stating that "never store encoded data". Does V1.1’s “stored” include caches, or is it database-specific?
How does ASVS reconcile V1.1's general principle of 'no encoding in storage' with V1.3.1's requirement for sanitization of HTML, where the sanitization process itself includes encoding literal characters (e.g., < to <) to produce safe HTML?
Which rule takes precedence, or is there a specific interpretation of V1.1 for HTML content that allows for the storage of these specific HTML entities (e.g., < for literal <) as part of its "safe semantic original state," even though it's technically an encoded form?
The problem to solve here is to use the correct caching mechanism.
The encoded data should be stored into the cache, if the data should be into the cache then would like to know the reason why we are stating that "never store encoded data". Does V1.1’s “stored” include caches, or is it database-specific?
I watch cache as a separate topic compared to storage (in the context of data integrity).
How does ASVS reconcile V1.1's general principle of 'no encoding in storage' with V1.3.1's requirement for sanitization of HTML, where the sanitization process itself includes encoding literal characters (e.g., < to <) to produce safe HTML?
Repeated here many times - sanitization is a different flow. It is up to business logic rules, what and how it is allowed to sanitize. WYSIWYG output does not require any additional encoding, if the content already contains HTML encoded characters such as <, then this is part of the WYSIWYG content as the original state.
Which rule takes precedence, or is there a specific interpretation of V1.1 for HTML content that allows for the storage of these specific HTML entities (e.g., < for literal <) as part of its "safe semantic original state," even though it's technically an encoded form?
I think the previous answer fits here as well.
I know you have excellent knowledge in this domain, and I’d like to ask for your perspective: How do you define “cache”, “stored”, “storage” and “double encoding”? What exactly is covered under each of these terms?
Get Outlook for iOShttps://aka.ms/o0ukef
From: Elar Lang @.> Sent: Friday, June 27, 2025 12:35:19 AM To: OWASP/ASVS @.> Cc: Ajay Ojha @.>; Author @.> Subject: Re: [OWASP/ASVS] Request for Clarification/Refinement: V1.1 "not stored in an encoded or escaped" Data Storage Principle (Issue #3206)
[https://avatars.githubusercontent.com/u/47597707?s=20&v=4]elarlang left a comment (OWASP/ASVS#3206)https://github.com/OWASP/ASVS/issues/3206#issuecomment-3009625531
The problem to solve here is to use the correct caching mechanism.
The encoded data should be stored into the cache, if the data should be into the cache then would like to know the reason why we are stating that "never store encoded data". Does V1.1’s “stored” include caches, or is it database-specific?
I watch cache as a separate topic compared to storage (in the context of data integrity).
How does ASVS reconcile V1.1's general principle of 'no encoding in storage' with V1.3.1's requirement for sanitization of HTML, where the sanitization process itself includes encoding literal characters (e.g., < to <) to produce safe HTML?
Repeated here many times - sanitization is a different flow. It is up to business logic rules, what and how it is allowed to sanitize. WYSIWYG output does not require any additional encoding, if the content already contains HTML encoded characters such as <, then this is part of the WYSIWYG content as the original state.
Which rule takes precedence, or is there a specific interpretation of V1.1 for HTML content that allows for the storage of these specific HTML entities (e.g., < for literal <) as part of its "safe semantic original state," even though it's technically an encoded form?
I think the previous answer fits here as well.
— Reply to this email directly, view it on GitHubhttps://github.com/OWASP/ASVS/issues/3206#issuecomment-3009625531, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AE3SS3W47LGULGN6XMA5ZLL3FQ767AVCNFSM6AAAAACAB7TIG2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMBZGYZDKNJTGE. You are receiving this because you authored the thread.Message ID: @.***>
I watch cache as a separate topic compared to storage (in the context of data integrity).
This is my interpretation — this opinion introduces a new concern: that anyone might treat caches as fundamentally less important for data integrity than databases. While this distinction might be valid in some simple architectures, in many real-world systems — especially in microservice or microfrontend architectures — caches are not just optimization layers, but often serve as primary data sources for performance-critical user flows.
This is getting quite offtopic and a bit philosophical here.
A "Separate topic" is a bit different than "less important"? You enter to cache poisoning area here, those are another set of requirements.
This is getting quite offtopic and a bit philosophical here. A "Separate topic" is a bit different than "less important"? You enter to cache poisoning area here, those are another set of requirements.
Sorry, But I disagree that this discussion is 'off-topic' or merely 'philosophical.' As a standard intended for practical application in application security verification, the precise terms like 'stored', 'original state,' and 'encoding' are fundamental and highly practical concerns for anyone implementing and verifying security controls, especially in complex modern architectures. I am fully aware of cache poisoning as a distinct vulnerability. My concern is fundamentally different,It's not about malicious content entering the cache (which cache poisoning covers).
my concern is on asvs v1.1's use of word "stored" & "not stored in an encoded or escaped form" in light of your suggestion to use caches for encoded data. your earlier response "cache is a separate topic compared to storage (in the context of data integrity)" is not align with the modern architectures realities and it opens a gate to the developer to store anything in cache(not malicious content). your response also create ambiguity in rule v1.1 as the rule says "not stored in an encoded or escaped form". Happy to know your further thoughts on this if any.
@elarlang would be great if you answer the below questions:
- I know you have excellent knowledge in this domain, and I’d like to ask for your perspective: How do you define “cache”, “stored”, “storage” and “double encoding”? What exactly is covered under each of these terms?
- What do you think that in what scenarios should output encoding be skipped (e.g., when data is already sanitized and encoded)?
Note: Please consider this message in a way that inexperience developer asking you a question and please don't think that I may not have a knowledge of all these words or skipped cases. The overall objective is wanted to know your thought and perspective.
What I said in response for "Repetitive UI rendering tasks increase the risk of inconsistent encoding, as developers may forget or incorrectly apply output encoding."
To ruin the original data to solve the caching problem from one output format is clearly an incorrect solution and an anti-pattern.
is not what you referred me to say
in light of your suggestion to use caches for encoded data
That is the second time in a row that I'm quoted or said to say something that I did not. I really don't like that. It also rises question, if those lines are misinterpreted as they are, what is the point or motivation to continue here.
Note: Please consider this message in a way that inexperience developer asking you a question and please don't think that I may not have a knowledge of all these words or skipped cases. The overall objective is wanted to know your thought and perspective.
It is 20+ comments here, and we have not moved anywhere. I'm happy to improve ASVS content, but this issue is playing with lines to provide free education. I don't feel the project/volunteer resources are well used here.
I believe your earlier message may have included only part of the full text. To ensure there’s no misunderstanding, here’s the full version you previously shared.
The problem to solve here is to use the correct caching mechanism. To ruin the original data to solve the caching problem from one output format is clearly an incorrect solution and an anti-pattern.
My interpretation — and I believe this is how many developers or architects might also interpret it:
The problem to solve here is to use the correct caching mechanism.
Caching is acceptable in terms of "correct caching mechanism"(using the cache appropriately).
To ruin the original data to solve the caching problem from one output format is clearly an incorrect solution and an anti-pattern.
I consider this as a warning about side effects of caching data in a transformed state and not a rejection to use of cache.
My Final Thought on the above quoted text: I didn’t ask whether caching should be used or not in the initial GitHub discussion ticket, i just highlighted the concern on the absolute stance in v1.1, its was you suggestion which I quoted above and I was not expecting technical solution.
My overall goal was to write the note to get a more detailed answer, so that other readers can also find a well-explained response without any confusion. My apologies if the note disturbed you.
I would request you please answer the questions which is asked in in my previous comment to align with the OWASP ASVS team thought on the requirement.
I'm happy to improve ASVS content, but this issue is playing with lines to provide free education.
If you believe this issue is just playing with lines to provide free education, then I would suggest not improving the ASVS content. Free educational material is available elsewhere, but what developers may not find easily is guidance on how to make their modern applications OWASP ASVS-compliant—especially when they face confusion or challenges with the written requirement, like I am facing challenges on the terms which is missing in the document.
The goal of this created ticket is request clarification which isn't clarified yet effectively because of the open questions based on real world challenges.
I was planning to submit this comment after your response as I didn't want to mix two topics in the same conversation. However, I think it's helpful to share the below perspective to think that whether the change/clarification is required or not.
The below quoted statements are not aligned with the modern micro-frontend or component-based architectures, where the same content may be rendered in multiple contexts.
the output from WYSIWYG is input for the application, the content is sanitized but never (additionally) encoded on the server side, as this is the original state to store, and this is also the exact value to use in the output.
WYSIWYG output does not require any additional encoding, if the content already contains HTML encoded characters such as <, then this is part of the WYSIWYG content as the original state.
The above statement assumes a single rendering context(HTML body), which doesn't hold in large-scale distributed frontend systems. if needed, I can share examples of vulnerable code that arise by directly following the quoted response.
Please refer the two use-cases, but different approach on "original state".
Use Case 1 (Simple Application): An Insurance Quote Website A lightweight quote generating application, only a few static pages are driven by content managed through an admin portal.
- Storing the WYSIWYG output and rendering is as-is might be acceptable.
- The usage context is controlled, and the HTML output goes directly to the DOM.
Note: It’s risky to rely entirely on the client-side editor’s value.
Use Case 2 (Medium.com-like Platform) Here, millions of user interact with the platform and contribute HTML-rich content via WYSIWYG editors
- Instead, I prefer to sanitize the WYSIWYG content server-side
- I decode any encoded characters as part of custom logic.
- I store the decoded, sanitized content.
- at output time, I encode at the appropriate service layer based on the target context.
I think the second approach is suitable for modern, high-risk application, there are lots of different ways to achieve the same security goal, the shared solution as per use case is one of them. but relying on the statement that "WYSIWYG output needs no extra encoding" is too broad and may lead to security anti-pattern.
In security, consistency and clarity are important, I believe a clarification/correction in the ASVS Document could benefit developers working in more complex architectures.
@earlang, I would appreciate answers to the open questions whenever time permits.
I'm happy to improve ASVS content
@elarlang, if you're still planning to update the content, it would be helpful if you could share what changes you're considering and the reasoning behind them.
@elarlang, I couldn’t find a definition for "original state" in the OWASP documentation (including main and subdomains) . It seems the term is only used in the ASVS document without sufficient clarification, leading to confusion. This is not the only one in the document there are a lot others which also requires clarifications.
So if I was to summarize what I understood here, the question is something along the lines of: "Are there niche cases where encoding would happen before data is stored."
I would agree that data stored from a WYSIWYG editor might meet that definition because by its nature it will only ever get used in a single way: to be rendered as UI.
We could potentially include an exception for this section for data that is only ever being used in a single way but I am not sure I see any other practical action from this issue. @ajayojha does that suggestion address your concern?
@ajayojha does that suggestion address your concern? No
Thank you @tghosth, I see multiple issues in the current V1.1 wording, but there are already ongoing discussions in other tickets, I may not be able to give enough time right now to continue this thread with detailed use cases and the specific concerns I have identified. I would suggest we revisit this discussion after a week. In the meantime, it would be helpful if @elarlang or any other core team member could share their thoughts on the open questions already raised in this ticket.
Here I am writing the questions:
- How do you define “cache”, “stored”, “storage” and “double encoding”? What exactly is covered under each of these terms in ASVS context?
- What do you think that in what scenarios should output encoding be skipped (e.g., when data is already sanitized and encoded)?
- I couldn’t find a definition for "original state" in the OWASP documentation (including main and subdomains) . It seems the term is only used in the ASVS document without sufficient clarification, leading to confusion. Please clarify with some usecases.
How do you define “cache”, “stored”, “storage” and “double encoding”? What exactly is covered under each of these terms in ASVS context?
Double encoding simply means doing an encoding operation twice meaning that when decoded once, the content will still appear with the encoding symbols instead of the unencoded form when rendered.
Stored/storage is generally referring to storing data in the application's data store.
I am not sure I see the relevance of caching here.
What do you think that in what scenarios should output encoding be skipped (e.g., when data is already sanitized and encoded)?
If WYSIWYG content has been sanitized using something like DOM sanitizer then it doesn't require further output encoding. Otherwise, I am not sure I see a scenario when output encoding should be skipped.
I couldn’t find a definition for "original state" in the OWASP documentation...
I think this just means the form in which the data was received into the system
concerning statement - "original state and is not stored in an encoded or escaped form (e.g., HTML encoding), to prevent double encoding issues"
If WYSIWYG content has been sanitized using something like DOM sanitizer then it doesn't require further output encoding.
Consider a case where a user has entered a value in the editor: 1 < " 2, and the written value is transformed after sanitization to 1 < " 2. The sanitized value is stored in the database field called content.
Now, while rendering on the UI, the developer is using the Bootstrap library to show the HTML content in a popover. As per the Bootstrap popover documentation, the value needs to be passed through an attribute property called data-bs-content.
Here is the HTML code with the content property value binding (the property value binding code is written in PHP)
<button type="button"
class="btn btn-primary"
data-bs-toggle="popover"
data-bs-placement="right"
data-bs-html="true"
title="Popover with HTML"
data-bs-html="true"
data-bs-content="<?php content ?>"> <!-- Server Side Rendering -->
Click to toggle popover
</button>
Do you think the above-mentioned sanitized value will perfectly bind to the attribute in the above code?
According to me
- The client-side sanitized content isn't the final one, isn't the right practice to suggest anyone.
- Writing that HTML sanitized content doesn't require output encoding isn't true unless the exact use case is known.
- Writing “never encode or escape the data at store because of the double encoding issue”: Will the issue be solved by performing output encoding or something else or will be the double encoding issue prevent in the above highlighted case? So the absolute stance “never encode or escape data at store” isn't correct without knowing the exact use case.
- The term “Original State” is not used in OWASP except in the ASVS V5 document. Let the project architect should decide how they want to safely handle the data. Saying that whatever data comes from a WYSIWYG editor is the original state isn't true.
- “Stored” - In modern application development, the data is stored in cache, permanent storage, temporary storage, messaging channels, etc., so writing “never store” isn't true. there are multiple use cases where this is required in different channels.
If data integrity is the primary concern, then frame the sentence in that way instead of writing "original state."
For the use case, please refer to this comment.