Input sanitization typically handles this as a string that only allows characters supported by the data type specified by the table field in question. A permissive strategy might scrub the string of unexpected characters. A strict one might throw an error. The point, however, is to prevent the evaluation of inputs as anything other than their intended type, whether or not reserved characters are present.
/me changes name to
'); DROP TABLE STUDENTS; --.Oh. Yes. Little Bobby Tables, we call him.
Dammit, Bobby!
Are there character escapes for SQL, to protect against stuff like that?
Only noobs get hit by this (called SQL injection). That’s why we have leads review code…
Yes but it’s a dangerous process. You should use paramatrized queries instead.
Yup, then it becomes a front-end problem to deal with wonky input. As a backend dev, this is ideal, just give me data and I’ll store it for ya.
Use parameters, that way data and queries are separate.
Input sanitization typically handles this as a string that only allows characters supported by the data type specified by the table field in question. A permissive strategy might scrub the string of unexpected characters. A strict one might throw an error. The point, however, is to prevent the evaluation of inputs as anything other than their intended type, whether or not reserved characters are present.