The csrf_meta_tag
inserts what is essentially a digitial signature into the page, acting as verification that requests coming into the application server are, in fact, from properly logged in users. This helps prevent cross-site scripting (a script on a completely unrelated page firing requests off to say, GMail, while you're logged into your GMail in another tab).
I guess to clarify, the csrf_meta_tag
itself doesn't prevent an unrelated page from firing off requests to your GMail (or any other service that is the target of the attack), but the "digital signature" in the csrf_meta_tag
is used to verify the validity of said requests. Invalid requests (i.e. from cross-site scripting attempts) should fail validation, and are therefore discarded.
To say it another way, from the attacker's point of view:
Before csrf_meta_tags
existed (they aren't exclusive to Rails by any means), successful cross-site scripting attacks allowed a malicious site to submit data to a web app in a way that makes the request appear as if it's being done on the user's behalf. So, let's say you're an admin on a web service, and in one browser tab you're logged into the admin panel for that service. If a malicious site open in another tab targeted your service for an attack, the malicious site might be able to run scripts that make admin requests, such as dumping list of users from the database, stealing other sensitive data, or potentially harming, damaging, or destroying data contained in the service, all while appearing (from the server's standpoint) to be valid requests from the admin themselves. The csrf_meta_tag
is a way to sign requests, and help thwart such attempts from being successful.
There's a much more detailed explanation available here.
It would also be educational to do a "view source" on one of your Rails-generated pages, and you'll see what the CSRF tag looks like.