Why am I confused?

1. So external scripts are dangerous, we hear that. But even if I do not include any external script, this still remains as a valid concern, right? Because someone evil do NOT really need me to include their evil scripts in order to steal information, they can just make the requests directly to my server? Without any form of authentication, my server cannot tell whether the request come from my page or anywhere else, and it’s bad if my server blindly return the JSON data to anyone, right?

2. If I understand correctly, the your proposed solution is something like this:

a. Have the server code authenticate the very first request. Assume valid credential, then create a secret and return along in the JSON payload.

b. In subsequent requests, have the server code authenticate using the secrets from previous responses and keep generate new secrets to send back in each response?

Thanks for clarifying.

In my application I’ve have escape utility, which escapes all special character to a standard ECMA character. Which will be like “&#”+charCode+”;”

This works in all cases like string to XML, string to HTML and XML to html.

when i try to use JSON as my data interchange format, it is not tokenizing my string which has got ECMA characters.

Thanks,
Sivaraj.

It basically says to incorporate rules on the server side to validate the referrer header as part of the authorization process.

However, I think this approach is equally vulnerable to an attack that exploits XSS to inject a rogue SCRIPT tag into the target application’s HTML. The rogue JavaScript will run in the application’s context, have access to its secretes, and requests it makes to your server (if well engineered) will be indistinguishable from legitimate requests.

-Tom

Additionally, we should consider the spectre of multiple tabs or windows. New authentication keys must be shared between open views. (Cookie-based storage of authentication keys?)