DEV Community: Ozan

🐳 CI/CD pipeline with Docker Scout

Ozan — Tue, 10 Nov 2026 11:42:56 +0000

You build the image, tag it, ship it... everything looks great. Then your security team flags a CVE in a package you didn’t even know was in there.

Docker Scout is Docker’s built-in vulnerability scanning and SBOM (Software Bill of Materials) tool. No extra install, no separate tooling: it scans your images against 20+ advisory sources (NVD, GitHub Advisory DB, CISA KEV, etc.) and lets you enforce policy evaluation before an image is allowed to ship. It turns container security from a one-time checkbox into a continuous process.

Worth knowing: Docker Scout isn’t the first attempt at this. Before Scout, Docker shipped docker scan, which relied on Snyk’s engine under the hood. Vulnerability scanning for local Docker images was introduced in late 2020 with the command docker scan. The Docker Scan command would use Snyk’s engine to scan Docker images for security vulnerabilities. The docker scan command is deprecated and will no longer be supported after April 13th, 2023. Run the docker scout cves command to continue to get vulnerabilities on your images. So Scout is Docker’s own engine, not a rebrand of the old plugin. itnext
dev

One more thing worth knowing: Docker Scout’s native Slack integration is being retired on July 30, 2026. So the practical move is to run docker scout cves / docker scout policy directly inside your pipeline and route the result to your own notification channel.

A minimal Jenkins step, report first, enforce once you trust the signal:

stage('Image Scan') {
    steps {
        script {
            // Report only for now. Flip exitCode to 1 to fail the build on HIGH/CRITICAL.
            def exitCode = sh(
                script: '''
                    docker scout cves myorg/backend:${GIT_COMMIT} \
                      --only-severity critical,high \
                      --exit-code 0
                ''',
                returnStatus: true
            )
            if (exitCode != 0) {
                slackSend(channel: '#ci-alerts', color: 'danger',
                    message: "Critical CVEs found in myorg/backend:${GIT_COMMIT}")
            }
        }
    }
}

Notification best practices, in short:
→ Alert only on HIGH/CRITICAL and pipeline failures, not every scan.
→ Keep webhook URLs in Jenkins Credentials, never in the Jenkinsfile.
→ A failed notification shouldn’t fail your build; wrap it, don’t gate on it.
→ The point: a broken build at 2am shouldn’t surface at 9am. Good alerting is signal, not noise.

Scan continuously, alert on what matters, decide your own threshold for when to block. That’s what makes container security part of the daily workflow instead of a quarterly audit.

Getting Real Client IPs Behind Cloudflare Proxy in Laravel

Ozan — Thu, 19 Feb 2026 13:58:00 +0000

If your server sits behind Cloudflare with a firewall that only allows
Cloudflare IP ranges, $request->ip() returns the Cloudflare proxy IP,
not the real client IP.

Why X-Forwarded-For Isn't Enough

The common advice is to use trustProxies(at: '*') and read
X-Forwarded-For. The problem: users can inject fake entries into this
header before it reaches Cloudflare, and Cloudflare appends rather than
replaces:

User sends:

X-Forwarded-For: 1.1.1.1

Cloudflare appends its own, resulting in:

X-Forwarded-For: 1.1.1.1, 26.55.52.xx, 172.70.216.62

With trustProxies(at: '*'), Laravel trusts everything and returns the
leftmost IP — the spoofed one.

CF-Connecting-IP Is the Right Header

Cloudflare sets CF-Connecting-IP to the actual connecting client IP and
strips any user-supplied header with the same name. It cannot be spoofed.

The Fix: A Simple Middleware

// app/Http/Middleware/CloudflareRealIp.php

  namespace App\Http\Middleware;

  use Closure;
  use Illuminate\Http\Request;
  use Symfony\Component\HttpFoundation\Response;

  class CloudflareRealIp
  {
      public function handle(Request $request, Closure $next): Response
      {
          $realIp = $request->header('CF-Connecting-IP');

            if ($realIp && filter_var($realIp, FILTER_VALIDATE_IP)) {
              $request->server->set('REMOTE_ADDR', $realIp);
              $request->headers->set('X-Forwarded-For', $realIp);
            }

          return $next($request);
      }
  }

->withMiddleware(function (Middleware $middleware): void {
      $middleware->prepend(CloudflareRealIp::class);
      $middleware->trustProxies(at: '*');
})

Why Not Check Cloudflare IP Ranges?

You might want to verify that the request actually comes from Cloudflare
before trusting CF-Connecting-IP. However, if your firewall already
blocks all non-Cloudflare traffic at the network level, this check is
redundant — and it breaks when a load balancer or internal proxy sits
between Cloudflare and your app (REMOTE_ADDR becomes an internal IP like
10.0.1.6 instead of a Cloudflare IP).

If you don't have a firewall, add the range check — but if you do, skip it.

Verify It Works

Add a quick debug route:

Route::get('/ip-check', function (Request $request) {
      return [
          'request_ip'      => $request->ip(),
          'remote_addr'     => $request->server('REMOTE_ADDR'),
          'x_forwarded_for' => $request->header('X-Forwarded-For'),
          'cf_connecting_ip'=> $request->header('CF-Connecting-IP'),
      ];
  });

Before the fix you'd see something like:

  {
    "request_ip": "172.70.216.62",
    "cf_connecting_ip": "26.55.52.xx"
  }

After the fix, request_ip matches cf_connecting_ip the real client IP.

Remove the debug route before going to production :))

Understanding Content Security Policy (CSP)

Ozan — Wed, 19 Nov 2025 17:14:37 +0000

TL;DR

CSP is an HTTP header that tells browsers "only run scripts from these trusted sources." It's your defense against XSS attacks where hackers inject malicious JavaScript into your site. Start with Content-Security-Policy-Report-Only to see what breaks, fix inline scripts by adding nonce attributes, whitelist external domains you trust, then enforce with Content-Security-Policy.

Test using Google's CSP Evaluator. Avoid 'unsafe-inline' and 'unsafe-eval' like the plague—they defeat the whole purpose.

Image Source: https://www.writesoftwarewell.com/content-security-policy/

Introduction

CSP (Content Security Policy) is basically a bouncer for your website. It tells the browser, "Hey, only let in scripts, images or fonts from these approved sources."

Why should you care? Because XSS (Cross-Site Scripting) attacks are everywhere, and CSP is one of the best ways to protect your users from them.

What is Content Security Policy?

Think of your website as a nightclub. Without CSP, anyone can walk in and start doing whatever they want. With CSP, you're the bouncer with a guest list—you explicitly tell the browser which scripts, styles, and other resources are allowed to run.

Here's the basic idea: instead of the browser trusting everything by default, you flip the script. You say "only trust content from these specific places, and block everything else."

A Simple Example

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

default-src 'self' - "By default, only load stuff from my own domain"
script-src 'self' https://trusted-cdn.com - "For JavaScript specifically, allow my domain and this one CDN I trust"

If someone tries to inject a <script> tag pointing to evil-hacker-site.com, the browser just... won't run it. Pretty neat, righ

It's Not Just About XSS

CSP also protects against:

Clickjacking - Someone embedding your site in an iframe to trick users
Mixed content attacks - Loading HTTP resources on HTTPS pages
Malicious iframes - Unexpected content being loaded into your page
Unauthorized data exfiltration - Scripts trying to send data to random domains

Think of it as security insurance. Your input validation might have a bug. Your sanitization library might miss something. CSP is there as a backup.

The Nonce Trick: When You Actually Need Inline Scripts

Okay, so you've got some inline JavaScript that you really need to keep inline. Maybe it's server-rendered data, or a legacy widget that's hard to refactor. What do you do?

Enter the nonce attribute. It's basically a one-time password for your inline scripts.

How Nonces Work

For every page request, your server generates a random, unguessable string:

   const nonce = crypto.randomBytes(16).toString('base64');
   // Result: something like "dGhpcyBpcyBhIG5v=="

Add this nonce to your CSP header:

   Content-Security-Policy: script-src 'self' 'nonce-dGhpcyBpcyBhIG5v=='

Add the same nonce to your inline script:

   <script nonce="dGhpcyBpcyBhIG5v==">
     console.log('This inline script is allowed!');
   </script>

The browser checks: "Does the nonce in the script match the nonce in the CSP header? Yes? Cool, run it."

Why this works: An attacker can't inject a script with the correct nonce because they don't know what the random value is. It changes with every page load.

Practical Example: Server-Side Rendering

Let's say you're using Node.js with Express and EJS:

app.get('/dashboard', (req, res) => {
  // Generate a random nonce
  const nonce = crypto.randomBytes(16).toString('base64');

  // Set CSP header with the nonce
  res.setHeader(
    'Content-Security-Policy',
    `script-src 'self' 'nonce-${nonce}'`
  );

  // Pass the nonce to your template
  res.render('dashboard', { nonce, userData: {...} });
});

In your EJS template:

<script nonce="<%= nonce %>">
  const userData = <%= JSON.stringify(userData) %>;
  console.log('User data loaded:', userData);
</script>

The nonce changes on every request, so even if an attacker sees it once, it's useless for their attack.

Important: What Nonces DON'T Protect Against

Nonces are great, but they won't save you from:

XSS vulnerabilities in your inline code itself
Scripts loaded from whitelisted domains that are compromised
JavaScript that's already on the page and gets called with malicious input

They're a way to say "this inline script is mine," not "this inline script is safe."

Key CSP Directives

Here are the most important directives you should know:

default-src: Fallback for other directives
script-src: Controls where scripts can be loaded from
style-src: Controls stylesheets
img-src: Controls images
connect-src: Controls AJAX, WebSocket, and fetch requests
font-src: Controls fonts
frame-src: Controls frames and iframes
frame-ancestors: Controls where your page can be embedded
base-uri: Controls the <base> tag
form-action: Controls form submission targets

Common CSP Values

'self': Same origin as the document
'none': Block everything
'unsafe-inline': Allow inline scripts/styles (avoid if possible!)
'unsafe-eval': Allow eval() and similar (avoid if possible!)
https:: Allow any HTTPS resource
https://example.com: Allow specific domain
'nonce-{random}': Allow specific inline script with matching nonce
'sha256-{hash}': Allow specific inline script with matching hash

How to Actually Implement CSP (Without Breaking Everything)

Here's the thing: you can't just slap a strict CSP on your site and call it a day. If you do, everything will break and your users will revolt. Trust me, many developers have learned this the hard way.

Here's the smart approach:

Step 1: Start in Report-Only Mode

Use the Content-Security-Policy-Report-Only header first:

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-violations

This is genius because the browser will:

Not block anything - Your site works normally
Report violations - You get a JSON report of what would have been blocked

You're basically doing a dry run.

Step 2: Set Up a Violation Report Endpoint

Create an endpoint to catch these reports:

// Example Express.js endpoint
app.post('/csp-violations', express.json({ type: 'application/csp-report' }), (req, res) => {
  console.log('CSP would have blocked:', req.body);
  // Maybe save to database for analysis
  res.status(204).end();
});

Or just use a service like report-uri.com that visualizes everything for you.

Step 3: Fix Your Code Based on Reports

You'll probably discover:

Inline scripts everywhere (especially in legacy code)
Scripts loaded from CDNs you forgot about
Third-party widgets that load their own stuff
Inline event handlers like onclick="doThing()"

Time to refactor! Move inline scripts to external files, or use nonce attributes (more on that in a sec).

Step 4: Switch to Enforcement Mode

Once the reports stop coming (or you've whitelisted legitimate sources), change from Content-Security-Policy-Report-Only to Content-Security-Policy.

Now you're actually protecting your users!

Step 5: Keep Both Headers Running

Pro tip: Keep report-only mode running even after you enforce. Use it to test stricter policies:

Content-Security-Policy: default-src 'self'
Content-Security-Policy-Report-Only: default-src 'none'; script-src 'self'

This way you can see what a stricter policy would break before you deploy it.

Testing Your CSP

Using Google's CSP Evaluator

Google provides an excellent tool for testing your CSP: CSP Evaluator

Simply paste your CSP header, and it will:

Highlight security issues
Suggest improvements
Explain potential vulnerabilities

Manual Testing

Check browser console: CSP violations appear in the console
Test inline scripts: Try adding an inline script—it should be blocked
Test external resources: Try loading resources from non-whitelisted domains
Use browser DevTools: Network tab shows blocked resources

Example Test

<!-- This should be blocked with a proper CSP -->
<script>alert('This is an inline script')</script>

<!-- This should also be blocked -->
<img src="https://untrusted-domain.com/image.jpg">

Common CSP Mistakes (And How to Fix Them)

1. Using 'unsafe-inline' (The Cardinal Sin)

Content-Security-Policy: script-src 'self' 'unsafe-inline'

Why this is terrible: This is like installing a security door and then leaving it wide open. It allows any inline script to run, including the ones attackers inject. You just defeated the entire purpose of CSP.

The fix: Use nonce attributes instead (see below) or move your scripts to external files.

2. Using 'unsafe-eval' (Also Bad)

Content-Security-Policy: script-src 'self' 'unsafe-eval'

Why this sucks: This allows eval(), new Function(), and similar code execution methods. Attackers love this.

The fix: Refactor your code. Modern JavaScript rarely needs eval(). If you think you need it, you probably don't.

3. Whitelisting Everything with Wildcards

Content-Security-Policy: script-src *

What you just did: "Allow scripts from literally anywhere on the internet"

The fix: Be specific. List the exact domains you trust.

4. Forgetting About base-uri

If you don't set base-uri, attackers can inject <base> tags to hijack relative URLs.

The fix: Always include base-uri 'self' or base-uri 'none' in your policy.

5. Whitelisting Entire CDNs

Content-Security-Policy: script-src 'self' https://cdnjs.cloudflare.com

The problem: CDNs host thousands of libraries. An attacker can use any of them, including old vulnerable versions of jQuery.

The fix: Use Subresource Integrity (SRI) hashes:

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.0/jquery.min.js"
        integrity="sha384-vtXRMe3mGCbOeY7l30aIg8H9p3GdeSe4IFlP6G8JMa7o7lXvnz3GFKzPxzJdPfGK"
        crossorigin="anonymous"></script>

Now the browser will only run it if the hash matches.

6. Trusting JSONP Endpoints

If you whitelist a domain that has JSONP endpoints, attackers can abuse them to bypass your CSP.

The fix: Don't whitelist domains with JSONP. Use CORS-enabled APIs instead.

Real-World Example: Strict CSP

Here's an example of a strict, production-ready CSP:

Content-Security-Policy: 
  default-src 'none';
  script-src 'self' 'nonce-{random}';
  style-src 'self' 'nonce-{random}';
  img-src 'self' https://trusted-images.com;
  font-src 'self';
  connect-src 'self' https://api.example.com;
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self';
  upgrade-insecure-requests;

This policy:

Blocks everything by default
Only allows scripts and styles from same origin with nonces
Restricts images to same origin and a trusted CDN
Prevents the page from being framed
Forces HTTPS upgrades

Best Practices

Start strict, then relax if needed: It's easier to add exceptions than to tighten a loose policy
Use nonces for inline scripts: Generate a new random nonce for each page load
Avoid 'unsafe-inline' and 'unsafe-eval': These significantly weaken your CSP
Monitor violations: Keep report-only mode running alongside enforcement
Use SRI for third-party resources: Add integrity checks to external scripts and styles
Keep your policy maintainable: Document why each source is whitelisted
Test thoroughly: Use automated tests to ensure CSP doesn't break functionality
Update regularly: As your app evolves, keep your CSP up to date

Beyond XSS: Other Security Benefits

Preventing Clickjacking

Content-Security-Policy: frame-ancestors 'none'

This prevents your site from being embedded in iframes, protecting against clickjacking attacks.

Enforcing HTTPS

Content-Security-Policy: upgrade-insecure-requests

This automatically upgrades HTTP requests to HTTPS.

Restricting Form Targets

Content-Security-Policy: form-action 'self'

This prevents forms from submitting to external domains, which could be used for phishing.

Debugging CSP Issues

When things don't work:

Check the console: CSP violations are logged with detailed information
Use Report-Only mode: Test changes without breaking production
Verify nonce generation: Ensure nonces are unique per request
Check for typos: CSP syntax is strict
Test in multiple browsers: Implementation may vary slightly

Wrapping Up

Look, CSP isn't a magic bullet. You still need to validate inputs, escape outputs, and follow other security best practices. But it's one of the most powerful tools in your security toolkit.

Here's what you need to remember:

The Good News:

CSP blocks most XSS attacks, even if your other defenses fail
Modern browsers all support it
It's not that hard to implement if you do it gradually

The Reality Check:

You can't just flip a switch—you need to refactor your code
Legacy codebases with inline scripts everywhere will be a pain
You'll probably break something in production at least once (we all do)

Your Action Plan:

Start with report-only mode TODAY (seriously, it's free intel)
Fix the low-hanging fruit (inline event handlers, obvious inline scripts)
Use nonces for the stuff you can't easily refactor
Test with Google's CSP Evaluator
Gradually tighten your policy over time

When You Really Need CSP:

You handle sensitive data (payments, healthcare, personal info)
You have user-generated content (comments, forums, profiles)
You want to sleep better at night

When You Can Probably Skip It:

Static blog with no user interaction
Internal tools behind authentication with no user input
You're just starting out and have bigger fish to fry

Final thought: Start strict and relax if needed. It's way easier than starting loose and trying to tighten things later.

Now go secure your websites! 🔒

Zero Downtime Deploy with PM2, Docker and Reverse Proxy

Ozan — Thu, 29 May 2025 10:52:25 +0000

Uptime is critical. Whether you're running a SaaS, API, or web platform, users expect availability—always. In this guide, we'll walk through how to achieve zero downtime deployments using PM2, Docker and a reverse proxy like NGINX.

Why Zero Downtime Matters

User Experience: No interruptions during new releases

Business Continuity: Prevent revenue loss during deploys

Stack Overview

App Runtime: Node.js with PM2

Containerization: Docker

Web Server / Proxy: NGINX or Caddy

CI/CD Tool: (Drone.io (my new favorite), Jenkins, GitHub Actions, etc.)

Step 1: Use PM2 to Manage the App Process

PM2 is a Node.js process manager that supports graceful restarts, monitoring, and clustering.

Example Dockerfile with PM2

FROM node:18

WORKDIR /app

# Add build-time env vars
ARG NEXT_PUBLIC_CDN_URL
ARG NEXT_PUBLIC_CDN_HOST
ENV NEXT_PUBLIC_CDN_URL=$NEXT_PUBLIC_CDN_URL
ENV NEXT_PUBLIC_CDN_HOST=$NEXT_PUBLIC_CDN_HOST

COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

RUN npm install -g pm2

EXPOSE 3000
CMD ["pm2-runtime", "start", "node_modules/next/dist/bin/next", "--", "start", "-p", "3000"]

Step 2: Create a Safe Docker Build + Deploy Flow

We will:

Build the Docker image

Run it on a temporary port

Perform health checks

If OK, swap it with the current live container

Example Shell Script (simplified)

docker build --no-cache -t app-latest .
docker run -d --name app-temp -p 3132:3000 app-latest

# Wait and test health
sleep 5
if docker exec app-temp curl -s http://localhost:3000 | grep -q '<title>'; then
  docker stop app-live && docker rm app-live
  docker stop app-temp && docker rm app-temp
  docker run -d --name app-live -p 3131:3000 app-latest
else
  echo "Health check failed. Aborting deploy."
  docker stop app-temp && docker rm app-temp
  exit 1
fi

Port 3132 is used temporarily; 3131 is the live port behind the reverse proxy.

Step 3: Set Up Reverse Proxy with NGINX

server {
  listen 80;

  location / {
    proxy_pass http://localhost:3131;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_cache_bypass $http_upgrade;
  }
}

NGINX routes traffic to the live container. When we swap containers on port 3131, traffic never notices.

Uptime Monitoring

Use tools like:

Uptime Kuma (Docker-based)
Better Uptime,
Upptime (hosted)

Set them to monitor /healthz or homepage on localhost:3131.

Security Tips

Avoid running Docker containers as root user

Don’t mount the Docker socket (/var/run/docker.sock) unless absolutely necessary

Use USER node or UID-based permissions in Dockerfile

Conclusion

Zero downtime deployment is achievable and maintainable with PM2, Docker, and a reverse proxy. This setup avoids user-facing errors, improves reliability, and keeps your engineering team confident in every release.

Want to go further? Add CI/CD integration with Drone or GitHub Actions and automate everything end-to-end.

That's all folks! ✨