In general for each sentense there should be clear goal, why it exists

The most common web application security weakness is using untrusted content in an unsafe context without first making it safe.

What the "first making it safe" means here?

I mean, the whole chapter is about how to make it safe, this is just the first line which summarised the issue.

Note from Josh, I think this section should maybe be moved further down as it is less important, I would consider it for 5.4

Input validation - sanitization - output encoding is logical way hot application process the input and it is the same order for testing it. So I prefer the order to stay.

So I see it as order of preference for solution, best is output encoding, then sanitization, then input validation as defense in depth

Input can come from a variety of sources including HTML form fields, REST requests, URL parameters, HTTP headers, cookies, files on disk, databases, external APIs, etc.

Everything the application uses or processes must be taken as user input, including HTML form fields, REST requests, URL parameters, HTTP headers, cookies, files on disk, databases, external APIs, etc.

What is the safe API?

What is your question? Are you saying that pretty much anything is untrusted input? I guess known constants might be considered trusted input...

My point of view is: not making it safe, but process it safely. Making it safe sounds like sanitization.

I guess known constants might be considered trusted input...

Philosophical, but I think is one of the main sources of why vulnerabilities happen.

For example, for output encoding, it does not matter, from where the input came. If the "trusted constant" contains symbols that require converting or escaping, you need to do it anyway.

Can you suggest alternative wording

Control Objective

A bit of content-heavy concentrate, but for serving the idea:

This chapter focuses on the most common web application security weaknesses that are related to unsafe processing of the data through the application from being technically correct - from missing or incorrect input validation if accepting the data to missing or incorrect way to encode, escape, or sanitize the data for the output or for the next component.

As the first line addresses 3 topics, but there are also V5.4 and V5.5 need to be addresed (although I have proposed to move those to V10 #1903)

Input validation

First line:
Everything the application uses or processes must be handled as user input, including HTML form fields, REST requests, URL parameters, HTTP headers, cookies, files on disk, databases, external APIs, etc.

Input validation provides valuable security hygiene and should be applied to all inputs where possible. However, since input validation is not able to prevent specific vulnerabilities, it should be used as a primary security defense. Other techniques detailed in later sections should be used as the primary defense against specific vulnerabilities.

This is quite far of being correct for me.

The message should be:
The goal for input validation is to provide data for the application in the expected format (this part duplicates the previous line a bit and needs some work) and it does not remove or replace the need to use correct encoding, escaping, or sanitization when using the data for next component or for presenting it for the output.

Or, just remove the line.

Output encoding

Ideally, safe APIs should be used which will do this automatically but otherwise the developer will need to take the required action.

What is the magic "safe API" that solves all the output problems? There is no such thing. As I don't understand the point or the message for the line, I can not provide any recommendations.

What is the magic "safe API" that solves all the output problems? There is no such thing.

However, there are many examples of functions in various languages that address specific security concerns. For instance, file I/O functions in several languages can prevent path traversal attacks, and functions that enforce the use of parameterized queries (like Criteria-based queries) protect against SQL injection.

While I’m not claiming that any single "safe API" can solve all output problems—that would be an oversimplification of what I was trying to say—there are many functions that, when used correctly, significantly improve security. These functions generally offer a safer, more reliable approach than handling such issues manually.

Here is recent article that talks about how using safe functions in certain languages have a dramatic effect on security. This is the general concept that I'm talking about.

https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html

@elarlang please let me know if you want further changes

One more thing can be done - as me and Jim did not share the idea to change the order for chapters, related HTML comments can be removed.