Dear NetMAKE - where can I find any information on this setting ?
The HELP file is terribly outdated 
[ATTACH=CONFIG]n73665[/ATTACH]
CSRF tokens is a must in our world. In all cases it work in a similar way, and it ensure a malicious site don’t do unwanted redirects from a customers browser into your application.
Courtesy of http://stackoverflow.com/questions/5…w-does-it-work
[B]Cross-Site Request Forgery (CSRF) in simple words[/B]
<ul>
<li>Assume you are currently logged into your online banking at www.mybank.com
<li>Assume a money transfer from mybank.com will result in a request of (conceptually) the form http://www.mybank.com/transfer?to=<SomeAccountnumber>;amount=<SomeAmount>. (Your account number is not needed, because it is implied by your login.)
<li>You visit www.cute-cat-pictures.org, not knowing that it is a malicious site.
<li>If the owner of that site knows the form of the above request (easy!) and correctly guesses you are logged into mybank.com (requires some luck!), they could include on their page a request like http://www.mybank.com/transfer?to=123456;amount=10000 (where 123456 is the number of their Cayman Islands account and 10000 is an amount that you previously thought you were [I]glad[/I] to possess).
<li>[I]You[/I] retrieved that www.cute-cat-pictures.org page, so [I]your[/I] browser will make that request.
<li>There is no way how your bank could recognize that the request was not made by you: Your web browser will send the request along with your www.mybank.com cookie and it will look perfectly legitimate. There goes your money!
</ul> [SIZE=15px]This is the world [B]without CSRF tokens[/B].[/SIZE]
[SIZE=15px]Now for the better one [B][I]with[/I] CSRF tokens[/B]:[/SIZE]
<ul>
<li>The transfer request is extended with a third argument: http://www.mybank.com/transfer?to=123456;amount=10000;token=31415926535897932384626433832795028841971.
<li>That token is a huge, impossible-to-guess random number that mybank.com will include on their own web page when they serve it to you. It is [I]different[/I] each time they serve any page to anybody.
<li>The attacker is not able to guess the token, is not able to convince your web browser to surrender it (if the browser works correctly...), and so the attacker will [I]not[/I] be able to create a valid request, because requests with the wrong token (or no token) will be refused by www.mybank.com.
</ul>
Thanks but your post does not explain how to use this feature. I’m not very familiar with extra security measures so while I kinda understand the concept I do not understand how this works in SC. It seems there are two sides involved in this procedure so I wonder what is the interaction of SC App with other sites with this is checked. Has anybody ever tested if it works (?) - is another question.
You don’t actually need to do anything extra after it was enabled, since the change is implicit. I did some tests with and without it. It does work. This is why someone can’t just pass a url to your app and transact based on input values.