Ajay Ojha
Ajay Ojha
I’m disappointed by the tone of your message, especially the suggestion that my statements are not serious or AI-generated simply because they are well-structured and assertive. I’ve engaged in this...
> In the big picture, it is clearer, but some details to improve. > > > strongly-typed ORM methods This is confusing, it's good use the term '**type-safe queries**' instead...
> So what do we think about: > > "_Verify that the application protects data selection or database queries (e.g., SQL, HQL, NoSQL, Cypher) against injection attacks by ensuring that...
> Preferred @tghosth Do you think the word “**preferred**” is the right fit for ASVS requirements, or is it good to stick to the standard wording like “**must**” or something...
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...
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...
Yes, I do understand the difference between sanitization and encoding completely.
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...
> 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...
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...