Understanding the Worst .NET Vulnerability

Re:Understanding the Worst .NET Vulnerability by jen20 on Tuesday October 28, 2025 @09:34AM (#45732699)

I don't know about "not targeting enterprise" being the problem here - it's super common to find "enterprise" .NET APIs that return 200 for every possible condition and put some error text as a JSON blob in the response with "success" = "false" while setting caching headers.

Mostly this stuff comes down to skill issues.

[ Parent | on HN ]

Re:Understanding the Worst .NET Vulnerability by j_w on Tuesday October 28, 2025 @01:24PM (#45735871)

At one point I interacted with an API that would return 200 for every condition, but with a "status" field that would have "OK" or "error", except on some browsers where it would use "OKAY" instead of "OK".

[ Parent | on HN ]

Re:Understanding the Worst .NET Vulnerability by PantaloonFlames on Tuesday October 28, 2025 @06:47PM (#45740292)

If I transmit SOAP or JSONRPC over http, both of which use the response payload itself to contain whether the request was an error or not, what should the status be in case of error ?

I jsonrpc I think 200 OK is correct with an error payload that says “you are not authorized” or similar.

[ Parent | on HN ]

Re:Understanding the Worst .NET Vulnerability by jen20 on Wednesday October 29, 2025 @01:52AM (#45743118)

> over http

> what should the status be in case of error

400 to 500 range status code. You can't ignore the lower level protocol because you're implementing a higher level one.

[ Parent | on HN ]