DEV Community: Ayman Eldawy

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.