A bank customer is signed in to online banking in one tab. In another tab they open a forum thread, and a hidden image tag on that page quietly tells the bank to transfer money. The bank sees a valid request carrying the customer's session cookie and carries it out. The customer clicked nothing, typed nothing, and never saw the transfer.
That is forgery, and along with directory traversal it is listed on the CompTIA Security+ SY0-801 exam under objective 2.5, which asks you to analyze indicators of malicious activity. These attacks abuse trust and paths rather than injecting code. Forgery comes in two forms that students constantly confuse, so this lesson keeps them clearly apart: cross-site request forgery, where the victim's browser is tricked, and server-side request forgery, where the server itself is tricked. Then it covers directory traversal, where an attacker walks out of the folder a web application meant to confine them, and the defenses for all three.
Forgery makes a trusted party send a request it never meant to
Both kinds of forgery share one idea: the attacker does not send the malicious request themselves, because their own request would not be trusted. Instead they get a party the target already trusts to send it. The question is always whose trust is being borrowed.
In cross-site request forgery (CSRF), the trusted party is the victim's browser, which holds an authenticated session with a site. In server-side request forgery (SSRF), the trusted party is the application server, which can reach internal systems the attacker cannot. Keeping straight which party is fooled is the key to scenario questions on this topic, so hold on to that single distinction as the sections below fill in the detail.
CSRF rides the victim's session to act as them
Cross-site request forgery tricks a logged-in user's browser into sending a request the user did not intend, to a site where they are already authenticated. It works because browsers automatically attach a site's cookies to any request bound for that site, even when the request is triggered from a different site. If the bank identifies the user by a session cookie alone, a request forged from anywhere carries that cookie and looks genuine.
The attack is set up on a page the attacker controls or has injected into. A hidden form that auto-submits, or an image tag whose source is a state-changing URL, fires the request as soon as the victim loads the page:
<img src="//bank.example/transfer?to=attacker&amount=5000">
The victim's browser requests that URL, attaches the bank cookie, and the bank processes a transfer. CSRF targets actions that change state, such as transfers, password changes, or settings updates, because the attacker cannot read the response; they can only cause the action. In the server logs the forged request looks ordinary, which is what makes CSRF hard to spot after the fact. The tell is contextual: a sensitive action that arrived without the normal navigation before it, or with a Referer or Origin header pointing at an unrelated site.
Two controls stop CSRF:
- Anti-CSRF tokens (synchronizer tokens): the server embeds a secret, unpredictable value in each legitimate form and checks it when the request comes back. An attacker's forged request cannot include the token because they cannot read it from another origin, so the request is rejected. This is the primary defense.
- SameSite cookies: a cookie attribute that tells the browser not to send the cookie on cross-site requests. With
SameSite=LaxorStrict, the bank cookie is not attached to the forum's hidden image request or a cross-site form post, so the forged request arrives unauthenticated. Lax still sends the cookie when the user clicks a link to the site, one more reason state-changing actions shouldn't use GET. Chromium-based browsers treat a cookie with no SameSite attribute asLax, which blunts many CSRF attacks on its own, but not every browser does, so set the attribute explicitly.
Requiring re-authentication or a confirmation step for the most sensitive actions adds a further layer.