Hacker News new | ask | show | jobs
by crote 194 days ago
Yeah, I was expecting something closer to "because that's what people Google for".

A big part of designing a security-related API is making it really easy and obvious to do the secure thing, and hide the insecure stuff behind a giant "here be dragons" sign. You want people to accidentally do the right thing, so you call your secure and insecure functions "setHTML" and "setUnsafeHTML" instead of "setSanitizedHTML" and "setHTML".

2 comments

100%… it’s like Rust’s “unsafe” package, or Rust reqwest package naming things like danger_accept_invalid_certs(true) and danger_accept_invalid_hostnames(true) → https://docs.rs/reqwest/latest/reqwest/struct.ClientBuilder....
get_magic_quotes_gpc() and mysql_real_escape_string() had quite a bit to teach in this area.
Both of those functions were deprecated years ago.

mysql_real_escape_string() was removed in PHP 7.0.

get_magic_quotes_gpc() was removed in PHP 8.0.

https://www.php.net/mysql_real_escape_string

https://www.php.net/get_magic_quotes_gpc

The current minimum PHP version that is supported for security fixes by the PHP community is 8.1: https://www.php.net/supported-versions.php

If you're still seeing this in 2025 (going on 2026), there are other systemic problems at play besides the PHP code.

mysql_real_escape_string is only deprecated because there is mysqli_real_escape_string. I always wondered why it's "real"...like is there "fake" version of it?
Yes.

https://www.php.net/manual/en/function.mysql-escape-string.p...

https://stackoverflow.com/questions/3665572/mysql-escape-str...

One hardly even tries to do the thing it says on the tin, the other one at least tries to be the real thing. None of them worked very well, however.

Hence why I chose "had" for my previous comment.
Decades ago.