Is there a field length that is too short to allow harmful SQL injection?

Without context, I'm going to presume that the author is referring to input fields in a client application. The easiest example to use would be a form in an HTML page in a web application, though what I'm about to describe is effective for virtually any type of client application.

Given this context, the answer is no, there is no maximum input field length short enough to protect you from SQL injection, because you don't control the maximum input field length. The attacker does. When the form containing the input field lives on the client (like in a browser window on the attacker's machine) it is outside of the trust boundary, and out of your control. It can be manipulated in any way the attacker wants or needs, or avoided completely. Remember, for a web app, all you get is an HTTP request. You have no idea how it was created, and no reason to believe that anything you asked the browser to do actually happened, that any client-side security controls were actually run, that anything in the request is as you intended or in any way safe.

So no, input field length is not a valid SQL injection prevention mechanism, and never, never trust input that crosses a security boundary without validating it.

No, there is no length that is too short to be exploitable (at least in some situations).

A length-filter is not a valid protection against SQL injection, and prepared statements really are the only proper defense.

A length filter is however a good measure as defense in depth (as are integer filters, alphanum filters, etc). There are many situations where e.g. valid input could never be above say 30 characters, but where meaningful exploitation requires more. It should (but probably doesn't) go without saying that any filtering as defense in depth must be taking place server-side as anything client-side can simply be bypassed.

Restriction Bypass

Restriction clauses (e.g. AND/OR) can be bypassed by two characters, which can cause real harm, not just a failed query. The most simple example is a login (other examples would be the unauthorized deletion of additional data):

SELECT * FROM users WHERE userid = [id] AND password = [password]

Injection:

id = 1#
password = wrong_password

Payload: 2 chars

DoS

DoS attacks require very few characters. In a MySQL example, it takes 7 for the actual call + x for the given seconds + whatever is needed to be able to call the function and fix the query.

Example:

SELECT * FROM users WHERE userid = [id]

Injection (this is a valid injection, a longer form would be 1 AND sleep(99)):

sleep(99)

Payload: 9 chars

Reading Data

If the data is displayed, the length depends mainly on the table and column name. I'll assume equal column count for all tables (it may happen, and it saves characters).

Example:

SELECT * FROM comments WHERE commentid = [id]

Injection:

1 union select * from users

Payload: 27 chars.

Editing Data

Unauthorized database modifications can also be achieved with few characters.

Example:

UPDATE users SET password = '[password]' WHERE id = [id]

Injection (into password):

',isadmin='1

Payload: 12 chars

A restriction bypass would also work (the result is that all passwords are now empty*):

'#

Payload: 2 chars

_{* The password example is used for simplicity; passwords should be hashed making the example impossible. The example still applies in all similar situations (updating a username, updating permissions, and so on)}

input fields as small as possible to reduce the likelihood of a hacker being able to squeeze SQL code into the field without it being truncated (which usually leads to a T-SQL syntax error).

IMHO, this is just shit. Using the length of input fields to protect from SQL injection is terrible advice:

• The only correct way to protect from SQL injection is the use of a prepared statement. The input data is a parameter of the query and will never be used as SQL text.
• The size of a field must be controlled server side because you can never trust what comes in a request - it might be a forged one - and should be used to sanitize data before usage in the business layer or database storage.
• Advice to use anything other than the best practices is confusing for novice developers.