Input sanitization typically handles this as a string that only allows characters supported by the data type specified by the table field in question. While in transit, the strings might be escaped at certain stages, such as via URL encoding. Though this is considered poor practice in many applications, it’s not uncommon to see. 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; --.Dammit, Bobby!
That boy ain’t right
Oh. Yes. Little Bobby Tables, we call him.
Are there character escapes for SQL, to protect against stuff like that?
Use parameters, that way data and queries are separate.
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.
Only noobs get hit by this (called SQL injection). That’s why we have leads review code…
Input sanitization typically handles this as a string that only allows characters supported by the data type specified by the table field in question. While in transit, the strings might be escaped at certain stages, such as via URL encoding. Though this is considered poor practice in many applications, it’s not uncommon to see. The point, however, is to prevent the evaluation of inputs as anything other than their intended type, whether or not reserved characters are present.