It has been seen that security testers input either ' or ; into the application entry points to test for SQL injection. Why are these characters used?

  • 10
    What research have you done? I expect you to do a significant amount of research before asking. Merely reading about how SQL injection works would probably be enough that you could answer this question on your own. Note that our about page says "IT Security Stack Exchange is for Information Security professionals", so this is usually not the right place to ask if you have no prior knowledge of security or have not tried to do any research about the topic you're asking about.
    – D.W.
    Commented Sep 24, 2014 at 0:01
  • 2
    Thank you for asking this question. There are no stupid questions and 9 years later, the helpful answers, links and discussion provided by this community make educating ourselves about security issues much more accessible.
    – Rae
    Commented Mar 14, 2023 at 22:13
  • xkcd.com/327
    – mcepl
    Commented May 20 at 12:13

3 Answers 3


The character ' is used because this is the character limiter in SQL. With ' you delimit strings and therefore you can test whether the strings are properly escaped in the targeted application or not. If they are not escaped directly you can end any string supplied to the application and add other SQL code after that.

The character ; is used to terminate SQL statements. If you can send the character ; to an application and it is not escaped outside a string (see above) then you can terminate any SQL statement and create a new one which leaves a security breach.


Read Wikipedia's examples of SQL injections, in particular the "Incorrectly filtered escape characters" section.

Essentially, in an injection you are expected to provide a ready-made command with a parameter. You build this parameter in such a way that it contains an embedded command, whilst respecting the syntax of SQL.

Since a command is typically SELECT FROM / UPDATE WHERE FOO='<your entry point>', you can use nop'; Your own command here. The combination of the two will give a sequence of two syntactically valid commands which will both be executed.

To prevent SQL injections, make you that you validate all untrusted input by verifying that it belongs to a white-listed domain of accepted inputs (here typically escape special characters), and also ensure that you delegate command composition to the DB API you use rather than doing it yourself: use a different call for providing the command and the parameters so the API you rely on can do additional checks and avoid you further embarassment!

  • 7
    Why is white-list character validation always considered the primary defense against SQL injection? I would use prepared statements with bind variables before I start hard-coding lists of allowed characters.
    – Brandon
    Commented Sep 23, 2014 at 20:03
  • 1
    I feel like the second part of your bold paragraph, regarding using a different call for the command and parameters, is basically hinting at prepared statements. Is that what you are suggesting?
    – Brandon
    Commented Sep 23, 2014 at 20:04
  • Thanks @Brandon I had forgotten the name prepared statements. White-listing good input rather black-listing bad input is a very general security principle, that applies to all forms of insecure interactions between components in particular. In other words you defined allowed strings in terms of what they can contain (e.g., properly formed UTF-8 characters with a length between 0 and whatever limit you enforce) rather than just checking the presence of "'" and ";" but maybe leaving corrupted data in your db (which may be valid but cause further issues in the app where proper UTF-8 is assumed) Commented Sep 23, 2014 at 21:28
  • 1
    Right, but if you use bind variables, the variables never get concatenated anyway, so white listing is moot at that point. White-listing requires maintenance and running a risk of preventing something that is safe and legitimate. Granted, sometimes there are things you need to concatenate or parameterize which don't support bind variables, like an ORDER BY clause. ORDER BY is a good use case for white-list validation.
    – Brandon
    Commented Sep 23, 2014 at 22:50
  • 1
    You're right, it feels frankly overkill... The "white-listing" for a UTF-8 string should be fairly straightfoward though, there are well defined ranges of allowed byte sequences. Even if a DB API ensured that an invalid UTF-8 string could be preserved as was provided, doing so would probably be a bad idea because you can't (reasonably :-) ) expect devs to remember to check every string manipulation function for errors. Commented Sep 23, 2014 at 23:12

Testers are trying to find bugs that they can get credit for finding; they are not trying to find the last remaining problem.

In most cases the input is checked before being passing into SQL by a well written function, or a parameter is used. Therefore it is likely that if even the most basic type of SQL-injection is stopped, then all types of SQL-injection is stopped for the given form field.

So just putting a in each entry point is a quick and easy way to get a lot of benefit for the tester and the tester's employer.

(Likewise a lot of tester will copy/paste in a very long bit of text, even if no user will ever do so, as it is a quick way to check if the application is coded to cope with inputs that are too long.)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .