DEV Community: Albert Einshutoin

Stop Hardcoding Security Headers: Automate Your CDN Security with YAML

Albert Einshutoin — Sun, 08 Feb 2026 19:44:22 +0000

Have you ever deployed a CloudFront Function or a Cloudflare Worker just to add a few security headers, only to break production because of a syntax error? Or worse, realized that your WAF rules and your application logic were completely out of sync?

I built cdn-security-framework to solve exactly this problem.

It’s an open-source CLI compiler that treats your CDN security policy as a single YAML file and automatically generates the necessary edge code (JS/TS) and infrastructure config (Terraform JSON).

Here is how it works.

The Problem: "Manual Sync" is a Bug
Usually, securing a CDN involves touching three different places:

Infrastructure: Configuring WAF rules (Terraform/Console).

Edge Logic: Writing JavaScript for viewer-request to filter headers or normalize URLs.

Application: Setting security headers like HSTS or CSP.

If you update one and forget the others, you create vulnerabilities. If you try to switch from AWS CloudFront to Cloudflare, you have to rewrite everything from scratch.

The Solution: Define Once, Compile Anywhere
Instead of writing code, you define a security.yml.

# policy/security.yml
version: 1
project: my-secure-app

request:
  # Block non-standard methods
  allow_methods: ["GET", "POST", "HEAD"]

  # Block bad bots by User-Agent
  block:
    ua_contains: ["sqlmap", "nikto"]

response_headers:
  # Inject security headers automatically
  hsts: "max-age=31536000; includeSubDomains"
  x_content_type_options: "nosniff"

firewall:
  # Generate WAF rate-limiting rules
  rate_limit: 2000

Then, you run the compiler:

npx cdn-security build

The tool automatically generates:

✅ Edge Code: Optimized JavaScript for CloudFront Functions (or TypeScript for Cloudflare Workers).

✅ WAF Rules: A Terraform-compatible JSON file defining rate limits and blocking rules.

Quick Start Tutorial

Installation Install the framework as a dev dependency in your project.

npm install --save-dev cdn-security-framework

Initialization Run the interactive init command. It will ask you about your platform (AWS/Cloudflare) and preferred security level (Strict/Balanced/Permissive).

npx cdn-security init

This creates a policy/security.yml file tailored to your needs.

Build & Deploy Compile your policy:

npx cdn-security build

Now take a look at dist/.

dist/edge/viewer-request.js: Contains the logic to block methods, filter User-Agents, and normalize requests. It handles all the edge cases for you.

dist/infra/waf-rules.tf.json: Contains the WAF rule definitions.

If you are using Terraform, you can simply import the generated WAF rules into your existing infrastructure without "taking over" your entire state.

# main.tf
resource "aws_wafv2_web_acl" "main" {
  name = "my-waf"
  # ... other config ...

  # Import the generated rule group
  rule {
    name     = "Imported-CDN-Security-Rules"
    priority = 10
    statement {
      rule_group_reference_statement {
        arn = aws_wafv2_rule_group.generated.arn
      }
    }
    override_action { none {} }
  }
}

Why I built this (and why you should use it)

Drift Detection The tool includes a script to check if your generated code matches your YAML policy. You can run this in your CI/CD pipeline to prevent "shadow edits" to the generated files.

# .github/workflows/ci.yml
- run: npx cdn-security build
- run: git diff --exit-code dist/

Polyglot Security
The same YAML policy can compile to AWS CloudFront Functions (JS) today, and Cloudflare Workers (TS) tomorrow. It abstracts away the runtime differences (e.g., crypto.subtle vs AWS restrictions) so you don't have to be an expert in every platform's quirks.
IaC Friendly
It doesn't try to apply changes to your cloud provider directly. It generates artifacts (code and JSON) that your existing deployment tools (Terraform, CDK, Serverless) can consume. This makes it safe to introduce into mature projects.

Give it a try!
I’d love to hear your feedback. Does this schema cover your security use cases? What features are missing?

NPM: cdn-security-framework

GitHub: Repo

Stop writing boilerplate security code by hand. Let the compiler do it.

I built a Node.js image engine in Rust to fix Sharp's deployment headaches

Albert Einshutoin — Sun, 28 Dec 2025 12:30:14 +0000

The "Dependency Hell" of Image Processing

If you've ever deployed a Node.js app that uses sharp to AWS Lambda or Alpine Linux, you know the pain.

"Error: 'vips/vips8' not found"
"Error: libvips.so.42: cannot open shared object file"

sharp is an incredible library—it's fast and the industry standard. But it relies on libvips, a C++ library that often requires complex OS-level dependencies (apt-get install, dynamic linking, etc.). This makes "Write once, run anywhere" feel like a lie when you move from macOS to Linux production environments.

So, I decided to fix it using Rust.

Meet lazy-image 🦀

I built lazy-image, a next-generation image processing engine for Node.js.

It is powered by Rust (via NAPI-RS) and uses statically linked binaries. This means:

Zero System Dependencies: No libvips installation needed. No apt-get. No LD_LIBRARY_PATH. Just npm install.
Memory Safety: The core logic is written in Rust, protecting your server from memory corruption bugs common in C/C++ libraries when processing user uploads.
Smaller Binaries: Instead of downloading a massive dependency chain, it uses platform-specific packages (~6-9MB).

Performance: Is it actually fast?

Yes. In fact, for many web-optimization tasks, it beats the competition.

Here is a benchmark result comparing lazy-image vs sharp (using mozjpeg + libvips):

Format	lazy-image	sharp	Difference
JPEG Size	15,790 bytes	17,495 bytes	-9.7% Smaller ✅
Pipeline Speed	193ms	273ms	1.41x Faster ⚡
PNG → AVIF	4,773ms	11,652ms	2.44x Faster ⚡

(Tested with 66MB PNG input, resized to 800px)

Why is it smaller?

I integrated mozjpeg by default, which uses advanced trellis quantization and scan optimization to shave off file size without losing visual quality.

Why is it faster?

For format conversions (like PNG to WebP) without resizing, lazy-image uses a Copy-on-Write (CoW) architecture. It avoids intermediate buffer allocations, making it significantly more memory-efficient and faster for batch processing pipelines.

How to use it

It's designed to be a drop-in replacement for your current workflow.

Installation

npm install @alberteinshutoin/lazy-image

Basic Usage


const { ImageEngine } = require('@alberteinshutoin/lazy-image');

// Memory-Efficient: Reads directly from file (bypassing Node.js heap)
await ImageEngine.fromPath('input.png')
  .resize(800)       // Resize to 800px width (auto height)
  .rotate(90)        // Rotate
  .grayscale()       // Apply filter
  .toFile('output.jpg', 'jpeg', 85);

Batch Processing
You can even process multiple images in parallel with a single engine definition:


const engine = ImageEngine.fromPath('template.jpg')
  .resize(800)
  .webp();

// Uses all CPU cores by default
await engine.processBatch(['img1.jpg', 'img2.jpg'], './output', 'webp');

Give it a try!
I built lazy-image to solve my own deployment headaches, but I think it can help many of you who are tired of wrestling with C++ dependencies in Node.js.

It supports JPEG, PNG, WebP, and AVIF.

Check it out on GitHub, and let me know what you think! I'm looking for feedback on the Rust/NAPI implementation.

👉 GitHub: https://github.com/albert-einshutoin/lazy-image
📦 npm: https://www.npmjs.com/package/@alberteinshutoin/lazy-image

node #rust #javascript #webdev