I'm currently implementing the default Struts2 token interceptor on all of our forms as a measure against CSRF (making a user unknowingly execute an action on our product by visiting another website and triggering malicious javascript).

Some technical specs on the token: when used, it creates 2 hidden fields on the form: a field called struts.token.name containing the name of the token, and a field with the name of the token and a randomly generated token. This token is also saved in the session, and the name of the token is stated in the configuration page. We configure each page token to have a unique name based on the name of the page and the ID of the token, if available. This is so a user can have 2 edit pages of the same type open, for example to copy over certain attributes from one object to the next.

When the page is submitted, a check is made whether the page contains a token of the name stated in the configuration page. If not, the page throws an error. If the token is present, a check is made whether the token is the same as the one stored in the session. If not, the page throws an error. If both checks pass, the page proceeds as normal.

My main concern is that a malicious page uses Javascript to retrieve the original page, append it to their own page and retrieve the relevant token fields to append them to their own request. Is that a legitimate concern?

1 Answer 1


If your application has CORS(Cross Origin Resource Sharing) enabled then yes, javascript code running in attacker page can make calls to your application, retrieve the token and send it in the next request which can result into cross site request forgery(CSRF).

However if CORS is disabled on your application then there is almost no way attacker can access your page and retrieve the tokens from it. CSRF attacks are usually done with the help of authenticated user by tricking them to click on some link running malicious code.

Struts token interceptor validate tokens once and then reset the token in Session object so that no one else can use the same token which could be due to CSRF attack or user trying to submit same request again(Multiple Form Sumission ).

You must log in to answer this question.

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