DEV Community: Olha Stefanishyna

Positive Security Models: From Block-Lists to Allow-Lists

Olha Stefanishyna — Wed, 09 Jul 2025 07:07:28 +0000

Hey DEV community! 👋

Ever wondered why your WAF lets some attacks slip through? Are you trying to block known bad stuff while allowing everything else?

What if I told you there's a better way? 🛡️

Positive security at infrastructure and application layers is that better way.
This approach protects against entire classes of attacks, including ones that don't exist yet.

Ready to flip your security paradigm?

👉 Read the complete article: "Building Fortress-First: The Power of Positive Security Models"

Happy securing! 🔒

Mastering Offscreen Rendering in WebGL

Olha Stefanishyna — Wed, 18 Jun 2025 11:17:05 +0000

Hey DEV community! 👋

Want to create cool post-processing effects in your WebGL projects, like bloom or motion blur? Or maybe you need to render a complex 3D scene to a texture for later use? Working with complex effects relies in understanding Framebuffers.

I've been diving deep into WebGL lately and wanted to share my journey of rendering scenes to a texture. This process is often called offscreen rendering.

In my latest article, I break down the entire process. We'll explore:

What Framebuffers are and why they are so essential in modern graphics.
The process of setting up your Framebuffer.
A practical example of how to render your scene to a texture and then use that texture on another object.

This technique opens up a whole new world of possibilities for advanced rendering and special effects.

Ready to take your WebGL skills to the next level?

👉 Read the full, detailed guide on my blog: "Rendering to Texture with Framebuffers in WebGL"

I've included code snippets and explanations to make it as clear as possible. Let me know what you think, and I'd love to see what you create with it!

Happy coding! ✨

Like my content? Follow me on X

Timing Attacks: Why Your Code Might Be Leaking Secrets

Olha Stefanishyna — Tue, 10 Jun 2025 04:17:07 +0000

Have you ever heard about side-channel attacks? They are a category of security attacks where attackers instead of breaking cryptography directly, analyze unintended information that "leaks" from the physical implementation of a system during normal operation.

Side-channel attacks are dangerous - even perfectly implemented cryptography can be vulnerable because of information leakage from the physical implementation of cryptographic systems. They may be invisible to standard security audits as it requires interdisciplinary knowledge to understand and prevent.

There are several types of the attack: timing attacks, cache timing attacks, power analysis attacks and others.

Timing attacks are one of the most common and accessible side-channel attacks because:

They can be performed remotely over networks
Don't require physical access to hardware
Can be executed with standard software tools
Often affect web applications and APIs directly

Understanding timing attacks

Instead of attacking the mathematical solution of your encryption algorithms, these attacks target how your code actually runs, allowing attackers to extract passwords, private keys, and other sensitive data simply by measuring response times. Timing attacks present unique challenges because they can bypass traditional security measures entirely.

In 2003, researchers David Brumley and Dan Boneh demonstrated extracting complete 1024-bit RSA private keys from SSL servers over a network using only timing analysis—requiring about one million queries over two hours. Their attack worked despite network jitter and proved that timing attacks are real danger for real systems.

The core principle is deceptively simple: execution time often correlates with specific properties of the secret like values and length.

For example, consider this condition:

'HELLO' === 'AAAA';

It is technically vulnerable because JavaScript engines (V8, SpiderMonkey) implement string comparison with an early exit for performance.

Testing "AAAA" against string "HELLO" fails on the first character (fastest), while "HAAA" fails on the second character (slightly slower), and "HEAA" fails on the third (even slower). An attacker can determine the correct string character-by-character, reducing the search space from exponential to linear complexity.

This is important - it is not a practical example because:

Timing differences are tiny - nanoseconds, not milliseconds
Network jitter drowns out these tiny differences
Nobody compares passwords directly (I hope so)

Let's consider more practical examples.

Real timing attacks exploit operations that take milliseconds, not nanoseconds. When a database lookup or cryptographic operation creates measurable delays, attackers can extract secrets even over noisy networks.

Authentication systems under attack

Authentication systems represent the highest-value target for timing attacks in web applications. When your authentication takes different amounts of time based on whether a username exists, or when your password comparison exits early on the first wrong character, you're broadcasting sensitive information through timing patterns.

function authenticate(username, password) {
    const user = database.getUser(username);

    if (!user) {
        return false; // Fast return - major timing leak
    }

    return bcrypt.compare(password, user.hashedPassword); // Slow operation
}

When an invalid username is provided, the function returns immediately. For valid usernames, the expensive bcrypt.compare() operation executes, creating a timing difference that's easily detectable across network connections.

Attackers can build complete lists of valid usernames before launching targeted password attacks.

API rate limiting and timing analysis

Rate limiting systems, designed to prevent abuse, often become timing attack vectors themselves. Timing-based rate limit detection allows attackers to map rate limiting thresholds and develop evasion strategies:

// Rate limiting creates timing patterns
app.use(
    rateLimit({
        windowMs: 15 * 60 * 1000, // 15 minutes
        max: 100, // Limit requests per window
        handler: (req, res) => {
            res.status(429).send('Too many requests'); // Immediate response
        },
    })
);

// Normal request: 200-500ms response
// Rate limited request: <10ms response (timing leak)

Rate-limited requests typically return immediately with error codes, while normal requests undergo full processing. This timing difference enables attackers to detect rate limiting activation and adjust their attack patterns accordingly.

What to do with the attack on the rate limiting systems? You may see suggestions like hiding rate limits.
Because visible rate limiting allows attackers to:

Map exact thresholds (e.g., "I can make exactly 99 requests before hitting the limit")
Optimize attack patterns to stay just under limits
Rotate through different IPs/sessions more efficiently
Time their attacks to reset windows perfectly

The idea is that uncertainty forces attackers to be more cautious. However, this is generally considered "security through obscurity" and not very effective - attackers can still discover the limits through probing.

I would suggest to consider rate limits as public information. They just should be sensible, but they may not be secrets.

You may learn more about rate-limiting at (Backend Rate Limiting)[https://dev.to/olha-stefanishyna/rate-limiting-architectural-layers-in-web-applications-3g76]

Modern defensive strategies and countermeasures

Defending against timing attacks requires a multi-layered approach combining constant-time programming, architectural defenses, and monitoring systems. The fundamental principle is ensuring that execution time remains independent of secret data.

Constant-time comparison functions

Constant-time comparison functions are the cornerstone of timing attack defense. Modern platforms provide built-in timing-safe comparison functions.

Dummy‐hash trick for passwords:
Make your login endpoint always invoke the slow password check, whether the username exists or not, so an attacker can’t time‐probe “does this user exist?”

//  Precompute a dummy hash once at startup:
const DUMMY_HASH = '$2b$12$K9QhMWzVN5YbRz5sXl0ueODhk0PtAyp7cVt2hx6Vj7XOx0JPTWm6W';

//  In your login handler, always do bcrypt.compare:
async function login(username, password) {
    const user = await db.findUser(username);
    // If user is missing, compare against the dummy hash
    const hashToCompare = user ? user.hash : DUMMY_HASH;
    const passwordValid = await bcrypt.compare(password, hashToCompare);

    if (!user || !passwordValid) {
        return { error: 'Invalid credentials' };
    }
    return { token: generateToken(user) };
}

Bcrypt’s .compare() is already designed to run in constant time per hash, but if you ever compare raw secrets (HMACs, tokens, API keys, etc.), you should never use ===. Instead do something like

const { timingSafeEqual } = require('crypto');

function safeCompare(a, b) {
    const bufA = Buffer.from(a);
    const bufB = Buffer.from(b);

    // If lengths differ, compare bufA to itself (constant time)
    // to prevent leaking the length of the secret
    if (bufA.length !== bufB.length) {
        timingSafeEqual(bufA, bufA);
        return false;
    }

    // true constant-time compare
    return timingSafeEqual(bufA, bufB);
}

Architectural defenses

Architectural defenses are system design patterns that eliminate timing attack vectors by restructuring how your application processes sensitive operations. Instead of fixing timing leaks in code, you redesign the system so timing information becomes meaningless to attackers.

Key Architectural Patterns:

Request/Response Decoupling
Response Caching Strategy
Uniform Processing Pipelines
Service Segregation

Let's look closer at Request/Response Decoupling:

// app/api/auth/forgot-password/route.js
import { addToQueue } from '@/lib/queue';

export async function POST(request) {
    const { email } = await request.json();

    // Queue the task instead of processing inline
    addToQueue('password-reset', {
        email,
        requestId: crypto.randomUUID(),
        timestamp: Date.now(),
    });

    // Return response immediately
    return Response.json({
        message: "If an account exists, you'll receive reset instructions",
    });
}

/** Background worker processes queue (runs separately) **/
// lib/workers/password-reset.js
export async function processPasswordReset({ email }) {
    const user = await findUserByEmail(email);

    if (user) {
        await sendPasswordResetEmail(user);
    }
    // No timing information leaks to the original requester
}

Monitoring systems

Monitoring systems are detection and analysis tools that identify timing attack attempts by analyzing request patterns, response times, and behavioral anomalies. Unlike rate limiting systems that prevent requests, monitoring systems are designed for detection. They observe and alert on suspicious patterns without blocking the traffic, allowing you to analyze potential attacks.

Start protecting your code today

Defending against timing attacks starts with three simple changes to your codebase:

Switch all secret comparisons to timing-safe functions
Implement dummy processing for authentication failures
Use libraries with built-in timing attack protection

Timing attacks are subtle but real. They won't show up in your unit tests or security scans. The best defense is understanding how they work and building protection into your code from the start by incorporating timing attack considerations into architectural decisions, development processes, and monitoring systems.

Conclusion

While the fundamental attack principles remain unchanged since Paul Kocher's pioneering work in 1996, timing attacks now affect a much broader range of applications - from browser JavaScript to backend services.

Success in defending against timing attacks requires combining multiple defensive layers: constant-time implementations at the code level, architectural protections like rate limiting and response normalization, comprehensive monitoring for attack detection, and regular security assessments to identify emerging vulnerabilities. By implementing these defenses systematically, development teams can build applications that resist even sophisticated timing attacks while maintaining the performance and functionality that users expect.

WebGL 2 Basics: Drawing a Full-Screen Quad

Olha Stefanishyna — Fri, 06 Jun 2025 12:47:12 +0000

As mentioned in the previous article, WebGL 2 uses a programmable pipeline.
This article covers shaders and GLSL language fundamentals - the essential building blocks before tackling fluid simulation.

Before creating complex effects, you need to understand how WebGL fundamentally renders anything to the screen. Unlike declarative approaches like HTML/CSS, WebGL requires to explicitly define the geometry and the appearance using custom programs. These programs, called shaders, are written in GLSL and executed directly on the GPU.

Introduction to GLSL ES 3.0

GLSL ES 3.0 (OpenGL Shading Language for Embedded Systems version 3.0) is a high-level shading language with a C-like syntax, specifically designed for graphics processing units (GPUs) in embedded systems and web browsers.
The GLSL ES 3.00 specification requires every shader to begin with #version 300 es to specify GLSL version for Embedded Systems. Without this directive, the shader won't compile. It also requires precision qualifiers in fragment shaders (e.g., precision mediump float;)

GLSL ES 3.0 Type System

Type System is the building blocks of GLSL ES 3.0 code. Understanding the type system will help declare variables correctly and use built-in functions without confusion.

Scalar Types

float (32-bit IEEE 754)
int (32-bit signed)
uint (32-bit unsigned)
bool

These are the simplest types: single numeric or boolean values.

Vector Types

Floating-point: vec2, vec3, vec4
Integer: ivec2, ivec3, ivec4
Unsigned: uvec2, uvec3, uvec4
Boolean: bvec2, bvec3, bvec4

GPUs process vector operations efficiently in parallel.

vec4 color = vec4(1.0, 0.5, 0.2, 1.0);
float r = color.r;     // Same as color.x or color[0]
vec3 bgr = color.bgr;  // Swizzle: vec3(0.2, 0.5, 1.0)

Matrix and Sampler Types

Matrices: mat2, mat3, mat4 (plus non-square variants)
Texture samplers: sampler2D, sampler3D, samplerCube
Integer samplers: isampler2D, usampler2D

A sampler type (e.g. sampler2D) tells the compiler you want to sample a 2D texture inside your shader. You’ll see these used in fragment shaders when you write expressions like texture(uTexture, vUV).

Variable Qualifiers

In GLSL, you also need to tell the compiler how data moves into and out of each shader stage. That’s where qualifiers like in, out, and uniform come in.

in: Input data (per-vertex in vertex shader, interpolated in fragment shader)
out: Output data (interpolated outputs in vertex shader, framebuffer outputs in fragment shader)
uniform: Constant values for entire draw call

Uniform Blocks

WebGL 2 supports grouping uniforms into blocks for efficient updates.
The GLSL code declares the uniform block structure in the shader:

layout(std140) uniform TransformBlock {
    mat4 model;
    mat4 view;
    mat4 projection;
} transform;

The JavaScript code creates a buffer and uploads data to match that structure:

// Create and bind uniform buffer
const ubo = gl.createBuffer();
gl.bindBuffer(gl.UNIFORM_BUFFER, ubo);
gl.bufferData(gl.UNIFORM_BUFFER, transformData, gl.DYNAMIC_DRAW);

// Associate with shader program
const blockIndex = gl.getUniformBlockIndex(program, 'TransformBlock');
gl.uniformBlockBinding(program, blockIndex, 0);
gl.bindBufferBase(gl.UNIFORM_BUFFER, 0, ubo);

The std140 layout is a standardized memory layout rule. It ensures all GPUs organize uniform buffer data the same way. Without this standard, your code might work on one graphics card but fail on another due to different memory arrangements.

WebGL 2 Vertex Specification Enhancements

WebGL 2 (GLSL ES 3.0) added several conveniences that cut down on boilerplate JavaScript and reduce errors when setting up vertex data.

Vertex Array Objects (VAOs)

Instead of binding and configuring each attribute (position, normal, UV, etc.) every time you draw, you can store that entire setup in a VAO.

VAOs encapsulate vertex attribute configuration, storing buffer bindings, attribute pointers, and enable states. This eliminates repetitive setup calls:

const vao = gl.createVertexArray();
gl.bindVertexArray(vao);
// Configure all attributes once
gl.bindVertexArray(null);

// Later: single call to use
gl.bindVertexArray(vao);
gl.drawArrays(gl.TRIANGLES, 0, vertexCount);

Explicit Attribute Locations

Instead of querying attribute indices at runtime with gl.getAttribLocation, you can hard-code the location right in your shader.

GLSL ES 3.0 supports explicit attribute location assignment, eliminating the need for getAttribLocation queries:

layout(location = 0) in vec2 aPosition;
layout(location = 1) in vec3 aColor;

JavaScript can then reference attributes numerically: gl.enableVertexAttribArray(0).

Shaders

A shader is a program written in GLSL for processing graphics data. There are two main types of shaders that work together to render graphics: the vertex shader and the fragment shader.

GLSL provides predefined built-in variables that handle communication between shader stages and the GPU.

Vertex Shader Built-ins:

gl_Position Must be written to the vertex shader. It’s the clip-space (x, y, z, w) output.
gl_VertexID Automatically provides the index of the current vertex (useful for procedural geometry).
gl_InstanceID When doing instanced draws, this tells you which instance you’re on.

Fragment Shader Built-ins:

gl_FragCoord The window-space coordinates (x, y, z, w) of the current fragment center, where z is depth and w is 1/w from clip space. gl_FragCoord.y uses bottom-left origin (OpenGL convention), so manual flipping may be needed for top-left origin coordinates.
gl_FrontFacing A boolean telling you whether the primitive was front-facing or back-facing.
gl_FragDepth Allows the fragment shader to write a custom value to the depth buffer

Vertex Shader

The vertex shader executes once per vertex with mandatory output gl_Position in clip-space coordinates. It receives per-vertex data through in variables and passes interpolated data to the fragment shader via out variables:

#version 300 es

in vec3 aPosition;  // Per-vertex position from buffer
in vec3 aColor;     // Per-vertex color from buffer
out vec3 vColor;    // Interpolated color for fragments

uniform mat4 uModelViewMatrix;    // Constant for all vertices
uniform mat4 uProjectionMatrix;   // Constant for all vertices

void main() {
    // Transform to clip space with w=1.0 for positions
    gl_Position = uProjectionMatrix * uModelViewMatrix * vec4(aPosition, 1.0);
    vColor = aColor;  // Pass color to fragment shader
}

After vertex shader execution, the GPU clips primitives outside the clip volume and then the GPU's fixed-function hardware automatically performs perspective division (dividing by the w component) to convert clip-space to Normalized Device Coordinates (NDC).

Compute in vertex shader when possible — few vertices in the vertex shader vs millions of pixels in the fragment shader.

Fragment Shader

After NDC producing, the GPU’s fixed-function maps NDC to window (pixel) coordinates. The rasterizer then converts triangles (defined by vertices) into fragments. Each fragment corresponds to a pixel location that the triangle covers. It contains: screen position (x, y), depth value (z), other interpolated values from vertex shader outputs.

The fragment shader runs once per fragment, receiving interpolated values from the vertex shader. The GPU automatically interpolates all vertex shader outputs across each triangle's surface:

#version 300 es
precision mediump float;

in vec3 vColor;      // Interpolated from vertex shader
out vec4 fragColor;  // RGBA output to framebuffer

void main() {
    fragColor = vec4(vColor, 1.0);  // Alpha = 1.0 for opaque
}

Output colors typically use a vec4 data type, representing red, green, blue, and Alpha (RGBA) components, with values often ranging from 0.0 to 1.0.

GPUs can trade accuracy for speed — using mediump instead of highp can improve performance on mobile devices while maintaining acceptable visual quality.

GPUs execute fragments in groups of threads (sometimes called warps or wavefronts). If a branch splits those threads — some go one way, some go another — the GPU ends up running both sides of the branch. That extra work makes branching less efficient:

// Efficient: branchless operations
float t = step(0.5, value); // Returns 0.0 or 1.0
vec3 result = mix(colorA, colorB, t);

// Inefficient: dynamic branching
vec3 result = (value > 0.5) ? colorB : colorA;

Full-Screen Quad Geometry

Many advanced GPU effects — from motion blur to fluid dynamics — are often implemented using two triangles that define a quad. These two triangles form a rectangle, invoking the fragment shader — once for every pixel. If it's full-screen, we call this a 'full-screen quad'. This technique allows you to run a fragment shader on every pixel of the screen or the quad's area.

A full-screen quad typically uses two triangles to cover the viewport because GPUs are highly optimized for processing triangles. This method ensures the entire rectangular area is consistently covered:

Full-Screen Quad Implementation

This implementation renders a full-screen quad. We'll create a visual test pattern by outputting UV coordinates as colors - this technique helps verify that our geometry covers the viewport correctly and that our coordinate mapping works as expected. This same setup will later serve as the foundation for post-processing effects.

Shaders

// Vertex Shader
#version 300 es
layout(location = 0) in vec2 aPosition;
out vec2 vUV;

void main() {
    gl_Position = vec4(aPosition, 0.0, 1.0);
    // Account for WebGL's bottom-left origin:
    vUV = aPosition * 0.5 + 0.5;
    // Flip Y for top-left texture origin
    vUV.y = 1.0 - vUV.y;
}

// Fragment Shader
#version 300 es
precision mediump float;
in vec2 vUV;
out vec4 fragColor;

void main() {
    fragColor = vec4(vUV, 0.5, 1.0);  // RG gradient visualization
}

JavaScript Setup

// Context acquisition
const gl = canvas.getContext('webgl2');
if (!gl) throw new Error('WebGL 2 not supported');

// Shader compilation
function compileShader(gl, source, type) {
    const shader = gl.createShader(type);
    gl.shaderSource(shader, source);
    gl.compileShader(shader);

    if (!gl.getShaderParameter(shader, gl.COMPILE_STATUS)) {
        const info = gl.getShaderInfoLog(shader);
        gl.deleteShader(shader);
        throw new Error(`Compile failed: ${info}`);
    }
    return shader;
}

// Program creation
function createProgram(gl, vertSrc, fragSrc) {
    const program = gl.createProgram();
    gl.attachShader(program, compileShader(gl, vertSrc, gl.VERTEX_SHADER));
    gl.attachShader(program, compileShader(gl, fragSrc, gl.FRAGMENT_SHADER));
    gl.linkProgram(program);

    if (!gl.getProgramParameter(program, gl.LINK_STATUS)) {
        throw new Error(`Link failed: ${gl.getProgramInfoLog(program)}`);
    }

    return program;
}

// Full-screen quad VAO
function createFullScreenQuad(gl) {
    const vao = gl.createVertexArray();
    gl.bindVertexArray(vao);

    // Two triangles: [-1,-1] to [1,1]
    const vertices = new Float32Array([
        -1, -1, 1, -1, -1, 1, // Triangle 1
        -1, 1, 1, -1, 1, 1, // Triangle 2
    ]);

    const buffer = gl.createBuffer();
    gl.bindBuffer(gl.ARRAY_BUFFER, buffer);
    gl.bufferData(gl.ARRAY_BUFFER, vertices, gl.STATIC_DRAW);

    gl.enableVertexAttribArray(0);
    gl.vertexAttribPointer(0, 2, gl.FLOAT, false, 0, 0);

    gl.bindVertexArray(null);
    return vao;
}

This implementation renders a full-screen quad with a UV coordinate gradient, serving as the foundation for post-processing effects and GPU-based computations.

Example: repo

Debugging Techniques

Debugging shaders presents unique challenges because they execute on the GPU, separate from the JavaScript environment. You can't simply use console.log() inside a GLSL shader to inspect values. So, you have to rely on specific techniques to understand program flow and data, helping to identify and fix issues.

Shader Compilation Checks

if (!gl.getShaderParameter(shader, gl.COMPILE_STATUS)) {
    console.error('Shader error:', gl.getShaderInfoLog(shader));
}

Visual Debugging

Output intermediate values as colors:

fragColor = vec4(vUV, 0.0, 1.0);                          // UV coordinates
fragColor = vec4(normalize(vNormal) * 0.5 + 0.5, 1.0);   // Normals

Summary

Full-screen quads provide the foundation for GPU image processing and simulations. Two triangles covering the viewport create a one-to-one fragment-to-pixel mapping, enabling parallel computation across the framebuffer. This technique underlies post-processing effects, fluid simulations, and GPU-accelerated algorithms.

This is part of my series on implementing interactive 3D visualizations with WebGL 2.

Getting Started with WebGL 2: Conceptual foundation

Olha Stefanishyna — Wed, 04 Jun 2025 16:32:14 +0000

Learning WebGL 2 can be challenging, but understanding its core concepts makes the journey easier. This introduction covers the essential concepts you need before writing your first WebGL program.

What is WebGL 2?

WebGL 2 (Web Graphics Library) is a JavaScript API that allows rendering interactive 2D and 3D graphics in compatible web browsers without requiring plugins. It's based on OpenGL ES (Embedded Systems), specifically designed for mobile devices and web applications.

This is fundamentally different from traditional DOM manipulation. While DOM operations primarily work with elements in a tree structure, WebGL 2 provides low-level access to your graphics card through the canvas element, allowing for hardware-accelerated graphics rendering.

Here's a simple example of initializing a WebGL 2 context:

// Get the canvas element
const canvas = document.getElementById('myCanvas');

// Initialize WebGL 2 context
const gl = canvas.getContext('webgl2');

if (!gl) {
    console.error('WebGL 2 not supported or enabled on this browser');
    // Fallback or error message
} else {
    console.log('WebGL 2 initialized successfully');
    // Continue with your WebGL 2 code
}

To better understand the difference in complexity between these APIs, let's compare what it takes to draw a simple red square in Canvas 2D and WebGL 2:

// CANVAS 2D API - Drawing a red square (3 lines of code)
const ctx = canvas.getContext('2d');
ctx.fillStyle = 'red'; // Set the color to red
ctx.fillRect(10, 10, 100, 100); // Draw a 100x100 square at position (10,10)

// WEBGL 2 - Drawing a red square (simplified, but still ~30 lines minimum)
const gl = canvas.getContext('webgl2');

// 1. Define vertex shader (runs once per vertex)
const vertexShaderSource = `#version 300 es
in vec4 a_position;
void main() {
  gl_Position = a_position;
}`;

// 2. Define fragment shader (runs once per pixel)
const fragmentShaderSource = `#version 300 es
precision highp float;
out vec4 outColor;
void main() {
  outColor = vec4(1.0, 0.0, 0.0, 1.0);  // Red color
}`;

// 3. Create and compile shaders
// ... (multiple lines of setup code omitted)

// 4. Create program and link shaders
// ... (more setup code omitted)

// 5. Define geometry for a square
// ... (more setup code omitted)

// 6. Finally draw
gl.clearColor(0.0, 0.0, 0.0, 1.0); // Clear to black
gl.clear(gl.COLOR_BUFFER_BIT);
gl.useProgram(program);
gl.bindVertexArray(vao);
gl.drawArrays(gl.TRIANGLE_STRIP, 0, 4); // Draw the square

This comparison illustrates the fundamental trade-off: Canvas 2D is designed for simplicity and requires minimal code for basic operations, while WebGL 2 demands more setup but gives you direct control over the GPU's rendering pipeline. This extra complexity enables the advanced 3D graphics and performance that WebGL 2 is designed for.

By leveraging GPU acceleration, WebGL 2 can render complex 3D scenes at 60fps or higher, enabling applications like:

Interactive 3D data visualizations
Browser-based games with sophisticated graphics
Architectural and product visualization tools
Physics simulations and particle systems
Image processing and filters with real-time performance

The cost? A steeper learning curve compared to other web technologies, but the payoff is tremendous visual power that was previously only available in native applications.

WebGL 2 as a State Machine

One of the first concepts needed to grasp is understanding that WebGL 2 functions as a state machine. This means its operations depend on previously set states rather than exclusively on parameters passed to functions - a fundamental characteristic that makes WebGL 2 different from typical JavaScript patterns.

In most JavaScript code, a function's behavior is determined primarily by the parameters you pass in:

// Regular JavaScript: behavior determined by parameters
const result = calculateSomething(paramA, paramB);

WebGL 2, however, works differently:

// Set a state
gl.useProgram(shaderProgram);
gl.uniform1f(uniformLocation, 0.5);

// This function's behavior depends on the states set above
gl.drawArrays(gl.TRIANGLES, 0, 3);

In this example, drawArrays() will use whatever shader program and uniform values were previously set. Understanding this state-based architecture is crucial for effective WebGL 2 programming.

The Programmable Pipeline

A fundamental aspect of WebGL 2 is its enhanced programmable pipeline, implemented through shader programs.

There are two mandatory shader programs that you need to write:

Vertex Shader: position vertices
Fragment Shader: color pixels

The programmable pipeline represents a fundamental shift from fixed-function graphics rendering to a flexible, developer-controlled system where you can write custom programs that execute directly on the GPU.

Before programmable shaders, graphics hardware used a "fixed-function pipeline" with built-in, unchangeable algorithms for:

Vertex transformation (multiply by matrices)
Lighting (typically Phong or Blinn-Phong model)
Texture mapping (basic sampling only)
Fog calculations
Color blending

The modern programmable pipeline mirrors the physical hardware architecture of GPUs and enables efficient parallel execution of custom rendering code, giving developers unprecedented control over visual output. We'll explore how to write these shader programs in detail in the next article.

WebGL 2 Coordinate System

Another important concept is the WebGL 2 coordinate system, which differs fundamentally from what web developers are used to in CSS.

In WebGL 2:

The origin (0,0) is located at the center of the canvas, not the top-left corner
The Y-axis points upward (positive is up), not downward
All coordinates are normalized between -1.0 and 1.0 regardless of canvas size

Understanding this coordinate system from the beginning helps prevent common positioning and orientation errors in your WebGL 2 projects.

What's Next

This post covered the WebGL 2 fundamentals. In upcoming articles, I'll deep dive into: shader techniques, performance optimization strategies, building a practical fluid simulation.

If you're working on graphics-heavy applications or need to squeeze more performance out of browser-based visualizations, WebGL 2's capabilities are worth the steeper learning curve.

Next article: WebGL 2 Basics: Drawing a Full-Screen Quad - Learn GLSL ES 3.0 and implement your first WebGL 2 program.

Rate Limiting: Architectural Layers in Web Applications

Olha Stefanishyna — Fri, 23 May 2025 14:14:31 +0000

Introduction

Rate limiting is a critical defensive strategy for web applications, allowing you to control the flow of incoming and outgoing requests. By restricting how many requests a client can make in a given time window, you can maintain system stability, prevent abuse, and ensure fair resource allocation across your user base.

This configuration demonstrates infrastructure-level rate limiting by setting request identifiers, allocating memory, defining burst-tolerant limits, and applying rules to specific URLs.

The Critical Role of Backend Rate Limiting

Effective backend rate limiting is foundational for:

System Stability: Prevents resource exhaustion during traffic spikes
Security Enhancement: Mitigates brute force attacks, credential stuffing, and DDoS attempts
Fair Resource Usage: Ensures equitable access for all users
Performance Optimization: Improves overall latency for legitimate users by smoothing request bursts

Backend rate limiting can be implemented across three distinct architectural layers, each operating at different points in the request lifecycle. These layers differ in their proximity to the client, available context, and performance characteristics. Understanding where each layer fits in your application architecture is crucial for designing an effective rate limiting strategy that balances early traffic filtering with granular business logic control.

Infrastructure Layer Rate Limiting

The infrastructure layer represents your first line of defense. At this level, rate limiting is typically implemented in load balancers and reverse proxies.

Key Advantages

Early Rejection: Blocks excessive traffic before it consumes application server resources.
Global Scope: Can enforce limits across all underlying services.
Performance: Typically implemented in highly optimized native code.

Example with Nginx

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

server {
    location /api/ {
        limit_req zone=mylimit burst=20 nodelay;
        proxy_pass http://my_upstream;
    }
}

This configuration illustrates how infrastructure-level rate limiting works by defining request identifiers, allocating tracking memory, setting rate limits with burst tolerance, and applying these rules to specific URL patterns.

Limitations and Considerations

While infrastructure-level rate limiting is powerful, it has limitations:

Typically relies on IP-based identification, which can penalize multiple users behind a NAT or corporate proxy.
CDN Interaction: If behind a CDN, ensure Nginx sees the actual client IP via headers like X-Forwarded-For.

For more granular control, consider using different identifiers by setting custom keys like API tokens:

# Use API key from header instead of IP
limit_req_zone $http_x_api_key zone=api_limits:10m rate=5r/s;

Application Gateway Layer Rate Limiting

This layer exists closer to the application, often within the application framework itself. In Next.js applications, this is often implemented using Middleware, which intercepts requests before they reach your route handlers.

Example: Next.js Middleware with in-memory rate limiter (for illustration only)

// middleware.js
import { NextRequest, NextResponse } from 'next/server';

const requestStore = /** In-memory request tracking **/;

export async function middleware(request) {
    if (request.nextUrl.pathname.startsWith('/api/protected-route')) {
        const ip = /** Extract client IP **/;

        const isRateLimited = /** Check if user exceeded rate limit **/;

        if (isRateLimited) {
            return new NextResponse('Too many requests.', {
                status: 429,
                headers: {
                    /** Standard rate limit headers **/
                },
            });
        }
        /** Update request tracking **/
    }
    return NextResponse.next();
}

export const config = {
    matcher: ['/api/:path*'],
};

Key Advantages of Middleware Rate Limiting

Edge Execution: Next.js Middleware can run at the edge, providing low latency decisions
Dynamic Rules: Easier to implement rules based on application state or user roles.
Contextual Awareness: Access to request headers, cookies, JWTs for finer-grained identifier choice.

Considerations

The in-memory approach shown here is purely illustrative. In any production environment, you should use a persistent, distributed store like Redis, or a specialized rate limiting service. In-memory solutions are unreliable because they lose state during restarts, deployments, or crashes, and can accumulate memory leaks over time.

Application Service Layer Rate Limiting

This involves implementing rate limits directly within the application's business logic, typically at the controller, service, or individual function level.
In Next.js rate limiting at the service layer is implemented directly in your API route handlers or server-side logic. This offers fine-grained control with the ability to integrate business rules.

Example - Next.js API Route with a simple in-memory store (Illustrative):

// pages/api/service-data.js

const requestTracker = /** Initialize request tracking **/;
const MAX_REQUESTS = /** Configure rate limit **/;
const WINDOW_MS = /** Define time window **/;

export default async function handler(req, res) {
    const identifier = /** Extract appropriate identifier (API key, user ID, or IP) **/;

    const recentRequests = /** Get user's requests within current time window **/;

    if (recentRequests.length >= MAX_REQUESTS) {
        return res.status(429).json({
            error: 'Too many requests. Please try again later.',
            retryAfter: /** Calculate retry time **/
        });
    }

    /** Update request tracking with current request **/
    /** Clean up old entries to prevent memory leaks **/

    res.status(200).json({ data: /** Return requested data **/ });
}

Considerations

Service layer rate limiting may affect performance, so this approach should be reserved for scenarios where middleware solutions aren't sufficient.

Standard Headers for Rate Limiting

Consistent client communication is key. Always include these HTTP headers in responses from rate-limited endpoints:

X-RateLimit-Limit: Maximum requests allowed in the current window
X-RateLimit-Remaining: Number of requests left in the current window
X-RateLimit-Reset: Unix timestamp or seconds until the limit resets
Retry-After: Seconds to wait before making another request (when rate limited)

Note that the IETF has a draft specification for standardized rate limiting headers, introducing RateLimit and RateLimit-Policy to consolidate rate limiting information. However, many APIs still use legacy headers with the X- prefix, such as X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset.

Best Practices for Backend Rate Limiting

Layered Approach: Combine infrastructure, gateway, and application-level limits for comprehensive protection.
Choose Appropriate Identifiers: Use IP for broad, unauthenticated traffic; API keys or user IDs for authenticated traffic.
Failure Handling: Decide whether to fail open (allow requests) or fail closed (block requests) when rate limiting services are unavailable.
Adaptive Limits: Consider implementing dynamic limits that adjust based on system health, user tiers, or traffic patterns.

Backend rate limiting is a multi-layered defense mechanism that protects your application while ensuring fair resource allocation. By implementing rate limiting at the infrastructure, gateway, and service layers, you create a robust system that can handle varying traffic patterns while preventing abuse.

Remember that well-implemented rate limiting should be invisible to normal users while protecting your system from abuse. When done right, it's an essential component of a resilient, scalable backend architecture.