Personally I want to call the element _DO_NOT_give_this_security_thingy_to_anybody_ever. An example scenario is some clever social engineers want the user to run a malicious "add a friend" and find the CSRF token stands in the way.

But is it worth it?

  • How is this name exposed to users? How long is the token good for? Aug 6, 2014 at 16:07
  • @MikeSamuel only in the source code, of course Aug 7, 2014 at 6:10

3 Answers 3


Call it that if you want - it doesn't affect the security of your system in any way.

At the end of the day, you can't protect against everything. If social engineering is involved, then the scammer could simply devise a reason for the user to give them the account password directly.

There are also other attacks that are difficult to defend against where users are involved, such as Self-XSS. This is where a scammer convinces a user to enter some JavaScript code into the browser dev tools with the promise of hacking somebody else's account.

A better approach to both these issues is to educate your users.


You should use tokens to prevent some "quick" spamming of your forms and requests in general. But actually the hacker can see the request with the whole query and notice that there is a token used. Once he got it he can build a spam bot using the random token your form is using.

A better way to be secure would be to use, lets say 3 (or more) tokens and a session value with a random number between the amount of tokens you use. So you can use the session value as a random pick for the token and validate it anywhere you want. So it is unpredictable because the $_SESSION data is hidden in the frontend.

Something like:

// Setting tokens
$_SESSION['token_1'] = "ocdja45d6"; // Any random value
$_SESSION['token_2'] = "62d5sas9f";
$_SESSION['token_3'] = "d8o9fhd5ds";
$_SESSION['random_token'] = mt_rand(1, 3);

// Getting Token
$randToken = 'token_' . $_SESSION['random_token'];
$token = $_SESSION[$randToken];

// Validating Token
if($token == $postTokenFromHackerOrUser)
    // Is okay or not?



Better look for other security issues, yes it can combat SE attacks, But why would you give DO_NOT_give_this_security_thingy_to_anybody_ever to a csrf-token name? make csrf token non-reusable, it'll solve the problem!

You must log in to answer this question.

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