Nice write up, can I go on a bit of a tangent, and talk about how Types can be used to prevent SQL Injection… specifically, we know we need to use parameterised queries, but mistakes still happen, so we can introduce the idea of a “literal-string” type (a string defined in the program, aka by the programmer), these can be concatenated together, but cannot include user data. Enforcing this type on the SQL string ensures that it’s safe from an Injection vulnerability. This can be done in Python and PHP today, but also in other languages via similar techniques: https://eiv.dev/
Very interesting stuff, thank you! In data science and analytics engineering we do a lot of query parametrization (with Liquid in the Mode BI tool, and with Jinja in the DBT data transformation tool). This is very unsafe but the thought process is that those tools are used internally in companies and there's no need to protect us from ourselves. I've never liked that excuse.
Good approach to use query parametrization; but for the bit about protecting against injection issues, my experience has been that mistakes unfortunately happen, especially when you have a junior developer editing existing code.
Nice write up, can I go on a bit of a tangent, and talk about how Types can be used to prevent SQL Injection… specifically, we know we need to use parameterised queries, but mistakes still happen, so we can introduce the idea of a “literal-string” type (a string defined in the program, aka by the programmer), these can be concatenated together, but cannot include user data. Enforcing this type on the SQL string ensures that it’s safe from an Injection vulnerability. This can be done in Python and PHP today, but also in other languages via similar techniques: https://eiv.dev/
Very interesting stuff, thank you! In data science and analytics engineering we do a lot of query parametrization (with Liquid in the Mode BI tool, and with Jinja in the DBT data transformation tool). This is very unsafe but the thought process is that those tools are used internally in companies and there's no need to protect us from ourselves. I've never liked that excuse.
Good approach to use query parametrization; but for the bit about protecting against injection issues, my experience has been that mistakes unfortunately happen, especially when you have a junior developer editing existing code.