[SoftTalker]

Another "can we please" is stop illustrating (or providing as defaults) insecure configuration examples.

A large percentage of people following the examples will use them verbatim.

Had a case recently where someone was setting up a postgres container and the example was something like:

    docker run --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -d postgres

You guessed it, "mysecretpassword" ended up being the password. And the service predictably got compromised, because that example was one that was pretty high up in seasrch results for "how to run postgres in docker" and attackers probing for port 5432 will try "mysecretpassword."

Another one is can we please stop posting code examples that are illustrating some language feature or how to do thing X in language Y, where the code has a footnote "this isn't secure, don't do this in production code." That footnote will be ignored. If you're going to bother answering a question, answer it with a proper implementation and not something that is a gaping code injection vulnerability.

[Terr_]

That could be improved if:

1. Software is coded to recognize "stupid example values" and prohibit them with an error or at least throw some pretty obvious warnings.

2. Such software also has a rarely-used but documented option to bypass the above checks.

For example, the PostgreSQL server might refuse to allow any DB user to have a password which begins with "password", returning a "Pick A Real One" error.

However somebody somewhere will always need the "don't do that" option: The more different libraries and services you bring together, the more likely there will be either false-alarms or outright conflicts between different example-blocker schemes.

[yencabulator]

My pet peeve is insecure configuration defaults. The Postgres container by default does not require any authentication for localhost connections, and with containers "localhost" can mean unexpected things.