Saturday 2 June 2018

Restricting Input Lengths

In any web application that requires user input, one of the decisions web developers often have to make is regarding the maximum length of a text field. No, not how many characters (though that is certainly pertinent), but where to implement it.

Why restrict the length?

Well, the main reason is security. If no length restrictions are in place, this leaves the door open for malicious input that could wreak havoc on an unprepared database. Restricting the length of a text field, however, cannot be the main line of defense. It should be one of the many safety checks in place.

Restricting from the back end

This basically involves specifying, at database schema level, how many characters your field will allow.

Here's an example.
CREATE TABLE Test (
    id int,
    name varchar(10)
);


If you attempt an SQL statement like this...
INSERT INTO test (id, name)
VALUES (1, "Ramabalakrishnan")


"Ramabalakrishnan" has more than 10 characters. Depending on your configuration, an error may be raised, or, more commonly, the input truncated.

Restricting from the front end

This is when you specify the restriction in your HTML like so...
<input type="text" maxlength="10" id="name" placeholder="Your name here" />


So when you attempt to enter in a very long line of text, it gets cut off at 10 characters. Try it!


Which is better? What's recommended?

To answer that question, let's examine the pros and cons of each approach.

While the back-end approach is undeniably more secure and no-nonsense, using it exclusively could be a user interface problem. Imagine typing a very long string into a textbox and having it truncated upon being saved. It's a visibility issue. Users generally have more confidence in a system when it performs as expected.

The front-end approach is very visible, and users know right off the bat that they can't enter more than a certain number of characters, because the textbox simply won't allow them to. But there's a catch... it's implemented at client-side, and any attacker worth his salt would know a ton of ways to defeat it.

So what now? Simple. There's no need to pick one over the other. Use both.

Having the restriction implemented at the front-end will make it far less annoying for users. Having it implemented additionally at the back-end is a security boost.

So long!
T___T

No comments:

Post a Comment