DEV Community: Ayman Eldawy

What Is CSRF (Cross-Site Request Forgery)?

Ayman Eldawy — Mon, 31 Aug 2026 11:23:43 +0000

You’re logged in to your bank account.

In another tab, you open a random website. Maybe it contains a malicious ad, or maybe the whole page is malicious.

That second website sends a request to your bank:

POST /transfer
amount=5000&to=attacker

You never opened the transfer page.

You never clicked “Confirm.”

But the request may still include your session cookie automatically.

And if the bank only checks that cookie, it may treat the request as if it came from you.

That’s Cross-Site Request Forgery, or CSRF.

The browser isn’t leaking your cookie

There’s an important distinction here.

The malicious website doesn’t necessarily need to read or steal your session cookie.

It only needs the browser to attach it to a request sent to the vulnerable website.

The attacker usually can’t read the response because of the browser’s same-origin policy. But for actions like changing an email address or transferring money, reading the response may not matter.

The damage is already done.

CSRF can target any state-changing action, such as:

Changing an email address
Updating a password
Transferring money
Deleting an account
Changing account settings

The exact impact depends on what the vulnerable endpoint allows.

How do CSRF tokens stop this?

One of the most common defenses is an anti-CSRF token.

The server generates a secret, unpredictable token associated with the user’s session and exposes it to the legitimate frontend.

When the frontend sends a state-changing request, it includes that token:

POST /transfer
X-CSRF-Token: random-secret-value

The server then compares the received token with the expected one.

If the token is missing or invalid, the request is rejected.

The attacker’s website might be able to trigger a request, but it cannot obtain the valid token from your website because of the browser’s same-origin protections.

That missing piece is what makes the forged request fail. CSRF tokens can be sent through hidden form fields, request bodies, or custom headers, depending on the application. OWASP’s CSRF Prevention Cheat Sheet

What about SameSite cookies?

The SameSite cookie attribute tells the browser when a cookie should be included with cross-site requests.

For example:

Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Lax

The available values include:

Strict: the cookie is only sent with same-site requests.
Lax: blocks the cookie on most cross-site subrequests, but still allows it during certain top-level navigations.
None: allows cross-site requests and requires Secure.

So SameSite makes many CSRF attacks much harder, but Lax doesn’t mean the cookie will never be included in a cross-site request. It’s better treated as one layer of protection rather than an excuse to ignore the rest of your CSRF defenses. MDN: Set-Cookie and SameSite

CSRF vs. XSS

The easiest mental model is:

With XSS, the attacker gets JavaScript to run inside the trusted website.
With CSRF, the attacker tricks the victim’s browser into sending an authenticated request to the trusted website.

XSS can often bypass CSRF protections because the malicious code is already running inside the application’s origin.

CSRF doesn’t need to steal your session.

It uses the session while it’s still sitting safely inside your browser.

This was post #4 in my Frontend Security series.

If you’d like to catch up on the previous posts:

Content Security Policy (CSP): Read the post
Cross-Site Scripting (XSS): Read the post
Where Should You Store Your JWT?: Read the post

More frontend security topics are coming soon.

What’s the difference between and ?

Ayman Eldawy — Tue, 25 Aug 2026 11:59:51 +0000

If you’ve ever hesitated between them, this post should make the choice a little clearer.

Let’s start with the one we use most: <img>

The <img> element displays a single image.

You give it a src, add an alt description for accessibility, and in many cases, that’s all you need.

<img
  src="image.jpg"
  alt="A developer working on a laptop"
>

Simple? But <img> can also handle responsive images using srcset and sizes:

<img
  src="image-600w.jpg"
  srcset="
    image-300w.jpg 300w,
    image-600w.jpg 600w,
    image-1200w.jpg 1200w
  "
  sizes="100vw"
  alt="A developer working on a laptop"
>

The browser can now choose the most suitable file based on factors such as the rendered image size, screen resolution, and the available candidates.

The content of the image stays the same.

Only the file dimensions change.

So <img> is usually enough when:

You need one image.
You need different sizes of the same image.
You don’t need to change its composition across screen sizes.

Then what is <picture> for?

<picture> lets you provide different image sources based on conditions such as viewport size or supported file format.

The important detail is that <picture> doesn’t replace <img>.

It works with it.

<picture>
  <source
    media="(min-width: 768px)"
    srcset="wide-image.jpg"
  >

  <source
    media="(max-width: 767px)"
    srcset="portrait-image.jpg"
  >

  <img
    src="default-image.jpg"
    alt="A developer working on a laptop"
  >
</picture>

Here, desktop users receive a wide image, while mobile users receive a portrait version.

This is known as art direction.

You’re not just serving a smaller file. You’re changing the crop or composition so the image fits the layout better.

<picture> can also help you serve modern formats with a fallback:

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">

  <img
    src="image.jpg"
    alt="A developer working on a laptop"
  >
</picture>

The browser checks the sources in order and selects the first format it supports.

If AVIF isn’t supported, it tries WebP.

If neither works, the <img> provides the JPG fallback.

So the choice is fairly simple:

Use <img> when you’re showing the same image, even if you need it in different sizes.

Use when you need to control which image is displayed based on its format, crop, composition, or a media condition.

So the difference is simpler than it first looks:

<img> chooses the best version of an image.
<picture> lets you define which image the browser should choose from.

Now you can stop making the browser solve your identity crisis between the two.

Does React Break HTML Rules? Let's Find Out

Ayman Eldawy — Sat, 15 Aug 2026 08:42:08 +0000

Can React create HTML that the browser itself wouldn't allow?

Sounds wrong, right?

That's what I thought too.

But while experimenting with React, I noticed something weird. So instead of guessing what's happening, let's break some HTML and see where it takes us.

And before looking at the results, try to guess what will happen yourself.

Let's Break Some HTML

Take this:

<p>
  Hello
  <div>World</div>
</p>

Nothing complicated.

Except it's invalid HTML.

A <p> element can only contain phrasing content, so a <div> can't live inside it.

Here's the first question:

What do you think the DOM will look like?

You might expect something like this:

p
├── "Hello"
└── div
    └── "World"

But open DevTools and inspect it.

You'll get something closer to:

<p>Hello</p>
<div>World</div>
<p></p>

The <div> is no longer inside the paragraph.

What happened?

When the HTML parser encounters the <div>, its parsing rules close the open <p> first. Later, when it reaches our original closing </p>, it has to deal with that too, which is why we can end up with that strange empty paragraph.

Okay.

We gave the browser invalid HTML, and the parser repaired it.

Fair enough.

Now let's annoy React with the same thing.

function App() {
  return (
    <p>
      Hello
      <div>World</div>
    </p>
  );
}

React warns us about the invalid nesting.

But here's where I originally got confused.

During client rendering, the DOM can still end up with that structure: the <div> inside the <p>.

Wait.

Didn't the browser just "fix" the exact same structure?

Why did one get repaired while the other didn't?

My first explanation was:

React handles HTML differently from the browser.

Not a terrible guess.

Also not quite right.

Maybe React Isn't the Interesting Part

Let's remove React completely.

Try this:

const p = document.createElement("p");
const div = document.createElement("div");

p.appendChild(div);
document.body.appendChild(p);

Inspect the DOM again.

We just constructed a <div> inside a <p> using plain JavaScript.

So...

React wasn't the important part after all.

The real difference is how we reached the DOM.

When the browser receives:

<p>
  <div></div>
</p>

it has HTML text that needs to be parsed.

Roughly:

HTML
  ↓
HTML parser
  ↓
DOM

The HTML parser has a surprisingly large set of rules for turning that text into a DOM tree, including rules for recovering from invalid markup.

But document.createElement() takes another path.

We're explicitly creating nodes and connecting them ourselves:

JavaScript
  ↓
DOM APIs
  ↓
DOM

There's no <p><div></div></p> HTML string going through the HTML parser in that example.

That's the part I was missing.

And it gives us a better way to think about what we saw with React.

JSX may look a lot like HTML, but during normal client rendering React isn't simply handing that JSX to the browser as an HTML document and asking the HTML parser to process it.

So two pieces of code can look almost identical while taking different paths to the DOM.

Okay, Let's Make It Weirder

Once I understood that, obviously I had to try more broken HTML.

Take this:

<image src="cat.png">

Quick guess.

What element do you think you'll find in the DOM?

<image>?

Nope.

The HTML parser has a wonderfully specific rule for this.

When it encounters an image start tag, it treats it as a parse error, changes the tag name to img, and processes it again.

So we end up with:

<img src="cat.png">

Yes, this behavior is actually in the HTML specification.

Now compare that with:

const element = document.createElement("image");
document.body.appendChild(element);

createElement() creates the element we requested. Because image isn't a recognized HTML element name, browsers represent it as an HTMLUnknownElement.

Again, we're not asking the HTML parser to interpret an <image> token.

We're constructing an element directly.

And suddenly what looked like:

"React is ignoring HTML rules."

looks more like:

"I was comparing HTML parsing with programmatic DOM construction."

Much better question.

Then SSR Enters the Room

At this point you could say:

"Cool. Weird browser trivia. I'll forget it tomorrow."

Fair.

But there's one place where this becomes very practical for React developers:

Server-side rendering.

With SSR, React produces HTML on the server.

That HTML reaches the browser.

Which means...

Yep.

We're back to the HTML parser.

React on the server
      ↓
     HTML
      ↓
 HTML parser
      ↓
     DOM
      ↓
React hydration

Now imagine the server sends invalid nesting.

Before hydration starts, the browser parses that HTML. If the parser repairs the structure, React can find a DOM tree that doesn't match what it expected to hydrate.

Hello, hydration mismatch.

React itself lists invalid HTML tag nesting as one possible cause of hydration failures.

So those invalid nesting warnings aren't React being dramatic for no reason.

Something that seems harmless while you're experimenting with client rendering can become a real problem once server-rendered HTML and hydration enter the picture.

So, Does React Break HTML Rules?

Not really.

My original question was slightly wrong.

I was treating "the browser" as if it were one single mechanism.

It isn't.

HTML text goes through the HTML parser, which has rules for building a DOM tree and recovering from invalid markup.

JavaScript can construct DOM nodes programmatically without sending the same HTML text through that parser.

And React's client rendering doesn't follow the same path as parsing a server-delivered HTML document.

With SSR, however, HTML parsing comes back into the picture.

So the next time the browser mysteriously "fixes" your HTML or React starts complaining about hydration, there's a useful question to ask:

Who built this DOM: the HTML parser, or JavaScript?

Oxlint vs ESLint: Which One Should You Use?

Ayman Eldawy — Tue, 21 Jul 2026 08:25:14 +0000

If you've worked with JavaScript or TypeScript, you've probably used ESLint at some point.

But recently, a new competitor has been gaining attention: Oxlint.

So, what's the difference, and which one should you choose?

Let's start with the basics.

What is a Linter?

A linter is a tool that analyzes your code and reports potential issues before they reach production.

Beyond catching bugs, it also helps teams maintain a consistent coding style by enforcing shared rules across the codebase.

In short, it keeps your code cleaner, more predictable, and easier to maintain.

ESLint

ESLint has been the standard linter for the JavaScript ecosystem for years.

If you've built a React, Next.js, Vue, or Node.js application, chances are you've already worked with it.

Pros

A massive ecosystem.
Thousands of plugins and shareable configurations.
Excellent support for React, Next.js, Vue, TypeScript, testing libraries, and more.
Easy to write custom rules.
Mature and battle-tested.

Cons

Performance can become an issue in large projects.
Every additional plugin increases linting time.
Configuration can become complex as projects grow.

Oxlint

Oxlint is a modern linter written in Rust, designed from the ground up with one goal: speed.

It's quickly becoming popular because of its impressive performance.

Pros

Often tens of times faster than ESLint.
Lower CPU and memory usage.
Simple setup with an excellent developer experience.
Great choice for large repositories and CI/CD pipelines.

Cons

The ecosystem is still much smaller than ESLint's.
Not every ESLint rule or plugin is supported yet.
Projects that rely heavily on custom ESLint plugins may still need ESLint.

Which one should you use?

Choose ESLint if:

You're working on an existing project.
Your project depends on many ESLint plugins.
You need custom linting rules.
You're using frameworks like Next.js with established ESLint configurations.

Choose Oxlint if:

You're starting a new project.
Performance is a top priority.
Your project doesn't rely on many ESLint plugins.
You want to significantly reduce linting time in CI.

Why not use both?

You don't necessarily have to choose one over the other.

Many teams combine them to get the best of both worlds.

A common workflow looks like this:

Use Oxlint during development for extremely fast feedback.
Run ESLint before commits or in CI to enforce all project-specific rules and plugins.

This approach provides a great developer experience without sacrificing the flexibility of ESLint.

Final thoughts

There's no universal winner.

ESLint wins when you need flexibility, a mature ecosystem, and extensive plugin support.
Oxlint wins when speed and developer experience are your highest priorities.

For many modern teams, using both is becoming an increasingly popular choice.

This is the first post in my new Frontend Battles series, where I'll compare popular frontend tools, libraries, and technologies to help you understand their strengths, trade-offs, and when to choose each one.

Where Should You Store Your JWT?

Ayman Eldawy — Wed, 15 Jul 2026 07:19:14 +0000

One of the first questions developers face when implementing an authentication flow is:

Where should I store the JWT?

After all, your application needs easy access to the token so it can send it in the Authorization header when making authenticated requests.

The two most common options are:

Local Storage
HttpOnly Cookies

Let's compare them.

Option 1: Local Storage

localStorage is a browser storage API that allows JavaScript to store and retrieve data.

Example:

localStorage.setItem("token", jwt);

The biggest advantage is convenience.

Your token is easy to access from anywhere in your frontend application.

However, that convenience comes with an important security trade-off.

Since JavaScript has full access to Local Storage, any JavaScript running on your page can also read your token.

If your application is vulnerable to Cross-Site Scripting (XSS) and an attacker manages to inject malicious JavaScript, they can simply read the token and send it to their own server.

That's one of the main reasons security professionals discourage storing JWTs in Local Storage.

But security isn't the only drawback.

Because Local Storage only exists in the browser, it isn't available during server-side rendering.

That means if your authentication relies on a token stored in Local Storage, your authenticated requests typically have to be made from the client.

For frameworks like Next.js, this means giving up many of the benefits of:

Server Components
Server-side rendering (SSR)
Server-side data fetching

Simply put, the server cannot access Local Storage.

Option 2: HttpOnly Cookies

A much more secure option is storing the token inside an HttpOnly Cookie.

The key advantage is that JavaScript cannot read HttpOnly cookies.

Even if an attacker successfully exploits an XSS vulnerability, they still can't directly access the token stored inside the cookie.

This provides a significant security improvement.

Another major benefit is that cookies are automatically included with requests to your server.

That means the token is available on both:

The client
The server

This is especially valuable in frameworks like Next.js, where Server Components and SSR often need access to the authenticated user's session.

Is HttpOnly Cookie always better?

Not necessarily.

Like most engineering decisions, it's a trade-off.

Local Storage

Pros

Very simple to implement
Easy to access from JavaScript
Works well for purely client-side applications

Cons

Vulnerable to XSS attacks
Not available during server-side rendering
Forces authentication logic to stay on the client

HttpOnly Cookies

Pros

Much more resistant to XSS attacks
Available to both the client and the server
Works naturally with SSR and Server Components

Cons

More complex to implement
Requires proper cookie configuration (HttpOnly, Secure, SameSite)
You also need to consider CSRF protection, since cookies are automatically sent with requests

So... which one should you choose?

For modern web applications—especially those built with frameworks like Next.js—HttpOnly Cookies are generally the recommended approach.

They provide stronger security, work seamlessly with server-side rendering, and align better with modern authentication architectures.

Local Storage is easier to use, but that convenience comes with meaningful security and architectural limitations.

This is the third post in my Frontend Security series.

Follow me to stay updated with the next episodes of my Frontend Security series

XSS Attacks

Ayman Eldawy — Mon, 06 Jul 2026 07:16:42 +0000

You’ve probably heard about Cross-Site Scripting (XSS) before, but did you know that it comes in multiple forms?

Each type targets a different part of your application, and understanding the differences is essential for building secure frontend applications.

Let's start with the basics.

What is XSS?

Cross-Site Scripting (XSS) is a security vulnerability that allows an attacker to inject malicious code, typically JavaScript, into a web page.

When that code is executed in another user's browser, the attacker may be able to:

Steal cookies or authentication tokens
Read sensitive information
Modify the page content
Perform actions on behalf of the user

Most XSS vulnerabilities happen because applications don't safely handle user input.

The three main types of XSS

Stored XSS
Reflected XSS
DOM-Based XSS

Let's look at each one.

1. Stored XSS

This is generally considered the most dangerous type of XSS.

It occurs when malicious user input is stored in the database and later displayed to other users without proper sanitization or output encoding.

Common places where this happens include:

Comments
Product reviews
Forum posts
User profiles

Imagine an attacker submits the following comment:

<script>
  // malicious JavaScript
</script>

If the application stores and renders that content without sanitizing it, every user who visits the page will execute the attacker's script.

That's why it's called "stored XSS"; the payload is permanently stored on the server.

Impact

Large-scale attacks affecting many users
Session hijacking
Account compromise
Data theft

How to prevent it

Validate and sanitize user input.
Apply proper output encoding before rendering content.
Use trusted sanitization libraries such as DOMPurify when rendering HTML.
Enable Content Security Policy (CSP) as an additional defense layer.

2. Reflected XSS

Unlike Stored XSS, the malicious payload is not stored anywhere.

Instead, it is reflected back to the user immediately through request data such as:

Search inputs
Query parameters
URL fragments

A common attack looks like this:

The attacker crafts a malicious URL.
The victim clicks the link.
The application reflects the input back into the page without escaping it.
The browser executes the injected JavaScript.

Because the payload only exists in that request, the victim must interact with the malicious link for the attack to work.

Impact

Cookie or token theft
Session hijacking
Redirecting users to phishing websites
Executing actions on behalf of the victim

How to prevent it

Validate incoming input.
Always apply proper output encoding.
Never render raw user input directly into HTML.
Enable Content Security Policy (CSP).

3. DOM-Based XSS

This type is especially important for frontend developers because the vulnerability exists entirely inside the browser.

The server may never be involved.

It happens when JavaScript reads data from an untrusted source and writes it directly into the DOM without proper sanitization.

Common unsafe APIs include:

innerHTML
outerHTML
insertAdjacentHTML
document.write()

If you're using React, you're already safer because React automatically escapes text by default.

However, that protection disappears when using APIs like:

dangerouslySetInnerHTML

If the HTML you're rendering comes from an untrusted source, you can easily introduce a DOM XSS vulnerability.

Impact

Data theft
Page manipulation
Executing arbitrary JavaScript
Session hijacking

How to prevent it

Avoid using innerHTML whenever possible.
Avoid dangerouslySetInnerHTML with untrusted content.
Sanitize HTML before rendering it.
Review dangerous DOM sinks in your application.

The golden rule

Never trust user input.

Whether the data comes from a form, a URL, an API, or even your own database, treat it as untrusted until you've validated, sanitized, and safely rendered it.

Defense against XSS isn't a single technique; it's a combination of secure coding practices, proper output encoding, sanitization, and browser protections like CSP.

This is the second post in my Frontend Security series.

In the previous post, we explored Content Security Policy (CSP) and how it helps mitigate XSS attacks.
if you'd like to check it out.
https://dev.to/aymaneldawy/what-is-content-security-policy-csp-p6p

What is Content Security Policy (CSP)?

Ayman Eldawy — Thu, 02 Jul 2026 07:43:56 +0000

One of the most important, yet often underrated, topics in frontend security is Content Security Policy (CSP).

You can think of CSP as a set of instructions you give the browser, telling it what is allowed to run and what should be blocked.

Let's break it down.

What is CSP?

Content Security Policy (CSP) is an HTTP response header that you configure on your server to tell the browser which sources are trusted for loading resources such as:

JavaScript
CSS
Images
Videos
Fonts
And other assets

Imagine the browser has a whitelist of trusted sources. Whenever it tries to load a resource, it checks whether that source is on the list.

If the source isn't trusted, the browser simply blocks it.

This makes it much harder for attackers to inject and execute malicious code on your website.

What problem does CSP solve?

The primary problem CSP helps mitigate is Cross-Site Scripting (XSS).

An XSS attack allows an attacker to inject malicious JavaScript into your application. Once executed, that script could:

Steal cookies
Read data from Local Storage
Modify the page
Perform actions on behalf of the user

How does CSP stop this?

Even if an attacker successfully injects JavaScript into your page, the browser will first check your CSP policy.

If that script doesn't come from an approved source, the browser refuses to execute it.

In many cases, the attack simply fails before any malicious code runs.

CSP helps with more than XSS

Although CSP is mainly known for mitigating XSS attacks, it can also help reduce other security risks, including:

Clickjacking
Loading untrusted third-party resources
Restricting iframes
Controlling redirects
Restricting form submissions
Controlling where images, fonts, stylesheets, and scripts can be loaded from

Despite being "just an HTTP header," CSP offers a surprisingly powerful security layer.

The downside?

Implementing a strict CSP can be challenging because you'll often need to carefully define every trusted resource your application depends on.

A simple example

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://example.com;

What does this mean?

default-src 'self'

By default, resources should only be loaded from your own domain.

script-src 'self' https://example.com

JavaScript is only allowed to execute if it comes from your own website or from https://example.com.
Any script loaded from another source will be blocked by the browser.

The stricter your policy becomes, the stronger your security.

Of course, finding the right balance between security and usability can take some effort.

If you're using Next.js, you can follow this guide to show you how to configure CSP in your application.
https://nextjs.org/docs/app/guides/content-security-policy

If you're using Angular, you'll also find official documentation covering CSP support.

This is the first post in a series about Frontend Security.

Over the next few posts, we'll explore more real-world security topics that every frontend developer should understand.