[intransigent]

Because many developers don't honestly believe that SQL represents a code execution boundary. Much of the time, the tendency is to think of SQL as simple I/O with a disk. And one rarely needs to worry about escaping interpretted expressions when streaming into and out of an I/O pipe.

They don't think of it as "executable code" because of the limited and monotonous nature of CRUD operations typically associated with data persistence.

They just think of it as yet another inconvenient form of declaritive data already at rest. Perhaps akin to mark-up. Raw data, like XML.

With JSON, some developers innately clue themselves in, because JavaScript, but they don't honestly understand the root of the hazard. They're just thinking FIRE BAD! Then they hack some JSONP into place because it's fun to do that sort of thing.

Most novice developers (my younger self included, tisk tisk) strongly resist protections against even HTML injection, until they see a massacre play itself out in the real world, when someone drops the ball.

[eganist]

This is also why smart money in appsec is focused on langsec and framework-integrated security controls, such as by forcing security patterns (e.g. html-context output encoding) by default and by compelling developers to work harder or, should they decide to break the rules, to do so more visibly.

[eganist]

("work harder to be wrong" specifically)

[xapata]

Reading XML ain't secure against malicious data either.

[int_19h]

I don't know why you're downvoted, because this is exactly correct.

https://www.vsecurity.com//download/publications/XMLDTDEntit...

Granted, most modern parsers disable the features that can trigger this by default. But there's still a lot of code out there compiled against libraries that did not, and some of that code is still updated and extended today.