• @TrickDacy@lemmy.world
    link
    fedilink
    138 months ago

    There are a lot of people who think that if a language or framework doesn’t completely disallow bad practices (and of course the authors have to agree with their very specific subjective ideas of what bad practices are) then it sucks. I’ve always found that weird. Like why are you mad at a tool for being “too flexible”? Why not be okay with learning what not to do?

    • @frezik@midwest.social
      link
      fedilink
      6
      edit-2
      8 months ago

      If you’re going to do that, then you also have to have a community that stresses best practices.

      In 1999, Perl was leading the world with a tutorial for DBI (its primary database driver interface then and now) that uses placeholders in its very first code example. The community made that the standard, and it was the first hit on “Perl SQL tutorial” on Google for a long time. Perl applications with SQL injection attacks are out there, but have been relatively uncommon.

      Notice that the API doesn’t force you to use placeholders. It’s simply strongly encouraged by the community.

      Also in 1999, PHP was leading the world in not having a database driver interface through a common API, but rather a thin wrapper over whatever C libraries were used for individual databases. If that database supported placeholders at all (MySQL didn’t, and guess which database was most popular with PHP?), then it often had a different syntax* for every one. (Note that Perl’s DBI uses a translation interface that can implement “?” as a placeholder for you if the underlying DB doesn’t do anything else or uses weird syntax). You could always use a filtering function, and PHP devs would routinely try to write their own rather than use the one that came with the database API that’s already vetted. Either way, there was no widespread community pressure to use safe practices, and PHP led the world in SQL injection vulnerabilities for well over a decade.

      *As a side note, I was recently accused by another dev of having a Python app riddled with SQL injection vulnerabilities. In fact, it was well protected, but it was using the psycopg interface to PostgreSQL, and it has a weird placeholder syntax that the other developer wasn’t familiar with. Thanks, psycopg!