DEV Community: Ítalo Queiroz

PNPM: Beyond Dependency Management - A Modern Alternative to NVM

Ítalo Queiroz — Sat, 30 Aug 2025 13:33:34 +0000

pnpm (performant npm) has already won over many developers with its efficiency in dependency management, but did you know it can also replace NVM for managing your Node.js versions? In this post, I'll show you how I use pnpm as a complete solution for my projects.

Why Consider PNPM?

Before diving into Node.js version management, let's recap the benefits of pnpm:

Space efficiency: Uses hard links and symbolic links to avoid package duplication
Speed: Faster installations than npm and yarn
Compatibility: Works with existing npm projects
Monorepos: Native and efficient workspace support

⚠️ Preparing the Environment: Necessary Cleanup

Important: To avoid conflicts and ensure a clean experience, I strongly recommend uninstalling NVM and Node.js before installing pnpm.

Uninstalling NVM

# 1. Remove the nvm directory
rm -rf ~/.nvm

# 2. Clean shell configurations
# Edit your ~/.bashrc, ~/.zshrc, ~/.profile and remove these lines:
# export NVM_DIR="$HOME/.nvm"
# [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
# [ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"

# 3. Reload the shell
source ~/.zshrc  # or ~/.bashrc

Uninstalling Node.js (if globally installed)

macOS (via Homebrew)

brew uninstall node
brew uninstall npm

macOS (manual installation)

# Remove Node.js
sudo rm -rf /usr/local/{bin/{node,npm},lib/node_modules/npm,lib/node,share/man/*/node.*}

# Clean cache
sudo rm -rf ~/.npm

Linux (Ubuntu/Debian)

# If installed via apt
sudo apt remove nodejs npm

# If installed via snap
sudo snap remove node

# Clean remaining files
sudo rm -rf /usr/local/bin/npm
sudo rm -rf /usr/local/share/man/man1/node*
sudo rm -rf /usr/local/lib/dtrace/node.d
sudo rm -rf ~/.npm
sudo rm -rf ~/.node-gyp

Verifying the Cleanup

# These commands should return "command not found"
node --version
npm --version
nvm --version

Installing PNPM

Recommendation: Use only curl or wget installation for a clean and controlled setup:

Via cURL (Recommended)

curl -fsSL https://get.pnpm.io/install.sh | sh -

Via wget (Alternative)

wget -qO- https://get.pnpm.io/install.sh | sh -

Configuring the PATH

After installation, add pnpm to your PATH:

# For zsh
echo 'export PATH="$HOME/.local/share/pnpm:$PATH"' >> ~/.zshrc

# For bash
echo 'export PATH="$HOME/.local/share/pnpm:$PATH"' >> ~/.bashrc

# Reload the shell
source ~/.zshrc  # or ~/.bashrc

Verifying the Installation

# Check if pnpm was installed correctly
pnpm --version

# Check location
which pnpm

Managing Node.js Versions with PNPM

Installing a Specific Version

pnpm offers commands similar to nvm for managing Node.js versions:

# Install the latest LTS version (20.x)
pnpm env use --global lts

# Install a specific version
pnpm env use --global 20.11.1

# Install the latest version (21.x)
pnpm env use --global latest

# Install a specific newer version
pnpm env use --global 21.7.3

Listing Available and Installed Versions

# View available remote versions
pnpm env list --remote

# View locally installed versions
pnpm env list

# View only remote LTS versions (20.x)
pnpm env list --remote lts

Using Versions per Project

One of the most interesting features is defining Node.js version per project:

# In your project directory
pnpm env use 20.11.1

# For projects that need newer features
pnpm env use 21.7.3

You can also specify the version in package.json:

{
  "name": "my-project",
  "engines": {
    "node": "20.11.1",
    "pnpm": "8.15.0"
  },
  "packageManager": "pnpm@8.15.0"
}

.pnpmrc Configuration

To further optimize pnpm usage, you can create a global .pnpmrc file:

# Create global configuration file
touch ~/.pnpmrc

Some useful configurations:

# ~/.pnpmrc

# Auto-install peer dependencies
auto-install-peers=true

# Use hard links when possible
use-node-version=20.11.1

# Configure global store
store-dir=~/.pnpm-store

# Enable hoisting for compatibility
hoist=true
shamefully-hoist=false

Complete Workflow: New Project

Here's my typical workflow for starting a new project after migration:

# 1. Check if pnpm is working
pnpm --version

# 2. Create project directory
mkdir my-new-project && cd my-new-project

# 3. Set Node.js version for the project (current LTS)
pnpm env use 20.11.1

# 4. Verify Node.js was installed correctly
node --version  # Should show v20.11.1
npm --version

# 5. Initialize project
pnpm init

# 6. Install dependencies
pnpm add react react-dom
pnpm add -D typescript @types/react @types/react-dom

Useful Daily Commands

# Switch between versions globally
pnpm env use --global 20.11.1
pnpm env use --global 21.7.3

# For projects needing experimental features
pnpm env use --global 22.0.0

# Remove an installed version
pnpm env remove --global 20.10.0

# See which version is active
pnpm env list

# Update pnpm
pnpm add -g pnpm

Comparison: PNPM vs NVM

Aspect	PNPM	NVM
Node.js Management	✅ Yes	✅ Yes
Dependency Management	✅ Excellent	❌ No
Performance	✅ Very fast	⚠️ Moderate
Space Efficiency	✅ Yes	❌ No
Compatibility	✅ Full	✅ Full
Per-Project Configuration	✅ Native	⚠️ Requires .nvmrc
Learning Curve	⚠️ Moderate	✅ Simple
Installation Conflicts	✅ Minimal	⚠️ Can occur

Tips and Tricks

1. Script for Automatic Version Switching

Create a script that automatically uses the correct version based on package.json:

# .zshrc or .bashrc
pnpm-auto() {
  if [[ -f package.json ]]; then
    local node_version=$(node -p "require('./package.json').engines?.node || '20.11.1'")
    pnpm env use $node_version
  fi
}

# Usage: pnpm-auto

2. Useful Aliases

# .zshrc or .bashrc
alias pn="pnpm"
alias pni="pnpm install"
alias pna="pnpm add"
alias pnr="pnpm run"
alias pnu="pnpm update"
alias pnv="pnpm env list"
alias pn20="pnpm env use 20.11.1"
alias pn21="pnpm env use 21.7.3"

3. Multi-Project Configuration Example

For different project types, you can have specific configurations:

# Modern React/Next.js project
pnpm env use 20.11.1

# Experimental project with edge features
pnpm env use 21.7.3

# Project needing latest features
pnpm env use latest

Potential Limitations

It's important to be aware of some limitations:

Adoption: Smaller user base compared to nvm
Documentation: Fewer online resources about Node.js management
Shell Scripts: Some scripts may assume nvm usage
Integration: Some tools may not automatically recognize
Very recent versions: Some bleeding-edge versions may take time to become available

Conclusion

pnpm has proven to be a versatile tool that goes beyond simple dependency management. For developers seeking a unified and performant solution, the complete migration from NVM to pnpm is a decision that significantly simplifies the development toolkit.

The combination of speed, space efficiency, and integrated functionality, along with a clean installation without conflicts, makes pnpm a modern and efficient alternative to the traditional npm + nvm combo.

NestJS ValidationPipe: Ensuring Secure Input Contracts

Ítalo Queiroz — Mon, 21 Jul 2025 00:52:48 +0000

In modern API development, ensuring that input data is in the correct format and valid is fundamental for application security and stability. NestJS offers an elegant and powerful solution for this need through the ValidationPipe, a built-in pipe that works in conjunction with validation decorators to create robust input contracts.

What is the ValidationPipe?

The ValidationPipe is a global NestJS pipe that automatically validates input data based on validation metadata defined through decorators. It uses the class-validator and class-transformer libraries to perform complex validations and data transformations in a declarative way.

Essential Configuration for Secure Contracts

new ValidationPipe({
  transform: true,
  whitelist: true,
  forbidNonWhitelisted: true
})

This configuration represents one of the best practices for ensuring secure input contracts. Let's analyze each property in detail:

Transform: Enabling Automatic Type Transformation

transform: true

What it does:

The transform property enables automatic transformation of input data into instances of the corresponding DTO (Data Transfer Object) classes. Without this option, the data remains as plain JavaScript objects.

Benefits:

Type Safety: Data is automatically converted to the correct types defined in the DTO
Enhanced Validation: Enables class-instance-based validations
Consistency: Ensures data always follows the expected structure

Practical Example:

// DTO
class CreateUserDto {
  @IsString()
  name: string;

  @IsNumber()
  @Min(0)
  age: number;

  @IsEmail()
  email: string;
}

// Controller
@Post('users')
createUser(@Body() createUserDto: CreateUserDto) {
  // With transform: true, createUserDto is an instance of CreateUserDto
  console.log(createUserDto instanceof CreateUserDto); // true

  // Data is automatically converted to the correct types
  console.log(typeof createUserDto.age); // 'number' (even when sending "25" as string)

  return this.userService.create(createUserDto);
}

Whitelist: Filtering Undeclared Properties

whitelist: true

What it does:

The whitelist property automatically removes any property from the input object that is not defined in the DTO through validation decorators.

Benefits:

Security: Prevents injection of unexpected properties
Data Cleaning: Automatically removes unnecessary data
Strict Control: Keeps only explicitly allowed data

Practical Example:

class CreateUserDto {
  @IsString()
  name: string;

  @IsEmail()
  email: string;
}

// Request body received:
{
  "name": "John",
  "email": "john@email.com",
  "password": "123456",        // ❌ Will be removed
  "isAdmin": true,             // ❌ Will be removed
  "maliciousScript": "<script>" // ❌ Will be removed
}

// Final object after whitelist:
{
  "name": "John",
  "email": "john@email.com"
  // Only properties with decorators are kept
}

ForbidNonWhitelisted: Rejecting Invalid Data

forbidNonWhitelisted: true

What it does:

This property goes beyond whitelist and generates an HTTP 400 (Bad Request) error when non-allowed properties are sent in the request.

Benefits:

Immediate Feedback: Informs the client about invalid data
Proactive Security: Blocks attempts to send malicious data
Easier Debugging: Helps developers identify contract errors

Practical Example:

class CreateUserDto {
  @IsString()
  name: string;

  @IsEmail()
  email: string;
}

// Request with non-allowed property:
{
  "name": "John",
  "email": "john@email.com",
  "unauthorizedField": "value"
}

// Result: HTTP 400 error with message:
{
  "statusCode": 400,
  "message": [
    "property unauthorizedField should not exist"
  ],
  "error": "Bad Request"
}

Complete Implementation: From DTO to Controller

1. Creating a Robust DTO

import { IsString, IsEmail, IsNumber, Min, Max, IsOptional } from 'class-validator';

export class CreateUserDto {
  @IsString()
  @Length(2, 50)
  name: string;

  @IsEmail()
  email: string;

  @IsNumber()
  @Min(18)
  @Max(120)
  age: number;

  @IsOptional()
  @IsString()
  bio?: string;
}

2. Configuring ValidationPipe Globally

// main.ts
import { ValidationPipe } from '@nestjs/common';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);

  app.useGlobalPipes(new ValidationPipe({
    transform: true,
    whitelist: true,
    forbidNonWhitelisted: true,
  }));

  await app.listen(3000);
}
bootstrap();

3. Using in Controller

@Controller('users')
export class UsersController {
  @Post()
  createUser(@Body() createUserDto: CreateUserDto) {
    // Data guaranteed to be valid and typed
    return this.userService.create(createUserDto);
  }
}

Advantages of Secure Input Contracts

1. Enhanced Security

Prevention of property injection attacks
Strict validation of data types
Blocking of malicious data

2. Maintainability

Clear and well-documented contracts
Centralized validations in DTOs
Reduction of manual validation code

3. Developer Experience

Type safety at compile time
Descriptive error messages
IDE auto-completion

4. Performance

Optimized validation
Efficient data transformation
Lower manual validation overhead

Advanced Use Cases

Conditional Validation

export class UpdateUserDto {
  @IsOptional()
  @IsString()
  name?: string;

  @IsOptional()
  @IsEmail()
  email?: string;

  @ValidateIf(o => o.email !== undefined)
  @IsString()
  @MinLength(8)
  password?: string;
}

Custom Validation

export class CreateUserDto {
  @IsString()
  @Validate(CustomUsernameValidator)
  username: string;
}

Conclusion

The ValidationPipe with the transform: true, whitelist: true, and forbidNonWhitelisted: true configurations represents a robust approach to ensuring secure input contracts in NestJS applications. This configuration offers:

Maximum security through filtering and rejection of unauthorized data
Type safety with automatic type transformation
Superior development experience with declarative validations and clear error messages

Implementing these practices from the beginning of the project ensures a solid foundation for secure, maintainable, and reliable APIs. The ValidationPipe is not just a validation tool, but a guardian that protects your application against malformed data and potential security vulnerabilities.

Implementing Multi-tenancy with Keycloak and NestJS

Ítalo Queiroz — Fri, 27 Jun 2025 22:44:55 +0000

Hey devs! 👋

If you've ever found yourself scratching your head trying to implement a system where different organizations (or clients) need their own isolated space, with their own users and configurations, you're probably dealing with multi-tenancy. In this article, I'll share a practical approach to implementing this using Keycloak and NestJS.

The Problem

Imagine you're building a SaaS and each client needs:

Their own isolated environment
Manage their own users
Have their own authentication settings
Be able to use different identity providers

Sounds complex? Well, that's where our solution with Keycloak and NestJS comes in!

Why Keycloak?

Keycloak is a powerful Identity and Access Management (IAM) tool that provides native support for multi-tenancy through "realms". Each realm is like an isolated mini authentication server, with its own settings, users, and clients.

The Solution

Let's break down our implementation into main parts:

1. Dynamic Realm Creation

First, we need a service that will manage our realms in Keycloak. Here's a simplified example:

@Injectable()
class KeycloakService {
  private kcAdminClient: KeycloakAdminClient;

  constructor(private configService: ConfigService) {
    this.kcAdminClient = new KeycloakAdminClient({
      baseUrl: this.configService.get('keycloak.url'),
      realmName: 'master'
    });
  }

  async createRealm(config: {
    organizationName: string;
    displayName: string;
    theme?: string;
  }) {
    await this.authenticate();

    const realmConfig = {
      realm: config.organizationName,
      displayName: config.displayName,
      enabled: true,
      sslRequired: 'external',
      loginTheme: config.theme || 'default',
      // Other security settings...
    };

    await this.kcAdminClient.realms.create(realmConfig);

    // Configure OAuth2 clients, default roles, etc...
  }
}

2. Tenant Identification Middleware

In each request, we need to identify which tenant (organization) is making the call. A common approach is to use a custom header:

@Injectable()
export class TenantMiddleware implements NestMiddleware {
  async use(req: Request, res: Response, next: NextFunction) {
    const organizationId = req.headers['x-organization-id'];

    if (!organizationId) {
      throw new UnauthorizedException('Organization ID is required');
    }

    req.tenantId = organizationId;
    next();
  }
}

3. Token Validation per Tenant

Each tenant has their own realm in Keycloak, so we need to validate tokens considering this:

export async function validateToken(token: string, organizationId: string) {
  const jwksClient = getJwksClient(organizationId);

  try {
    const decodedToken = jwt.decode(token, { complete: true });
    const key = await jwksClient.getSigningKey(decodedToken.header.kid);

    return jwt.verify(token, key.getPublicKey(), {
      algorithms: ['RS256'],
      issuer: `${KEYCLOAK_URL}/realms/${organizationId}`
    });
  } catch (error) {
    throw new UnauthorizedException('Invalid token');
  }
}

4. Keycloak Context Decorator

To facilitate access to the Keycloak admin client in the current tenant context:

export const KeycloakContext = createParamDecorator(
  async (data: unknown, ctx: ExecutionContext) => {
    const request = ctx.switchToHttp().getRequest();
    const organizationId = request.tenantId;

    const adminClient = new KeycloakAdminClient({
      baseUrl: KEYCLOAK_URL
    });

    await adminClient.auth({
      grantType: 'client_credentials',
      clientId: 'admin-cli',
      clientSecret: ADMIN_SECRET
    });

    adminClient.setConfig({ realmName: organizationId });

    return {
      adminClient,
      realm: organizationId
    };
  }
);

5. Using in a Controller

Now we can put it all together in a controller:

@Controller('users')
export class UserController {
  @Post()
  async createUser(
    @KeycloakContext() kc: KeycloakContext,
    @Body() userData: CreateUserDto
  ) {
    const { adminClient, realm } = kc;

    // Create user in the tenant-specific realm
    const user = await adminClient.users.create({
      realm,
      username: userData.email,
      email: userData.email,
      enabled: true,
      // other properties...
    });

    return user;
  }
}

Tips and Considerations

Smart Caching: Implement caching for JWT tokens and user information, but remember to separate by tenant!
Data Migration: Have a clear strategy for data migration when creating new tenants.
Monitoring: Add detailed logs to debug tenant-specific issues.
Testing: Create tests that validate isolation between tenants.

Conclusion

Implementing multi-tenancy might seem daunting at first, but with the right tools (like Keycloak and NestJS) and a well-thought-out architecture, we can create a robust and scalable solution.

The code I showed here is just the tip of the iceberg, there's much more to consider like per-tenant database management, distributed caching, per-organization rate limiting, etc. But that's a topic for another article! 😉

Keycloak and Okta Integration: Complete Developer Guide

Ítalo Queiroz — Sat, 07 Jun 2025 20:45:50 +0000

Introduction

Identity management and authentication are fundamental pillars of security in modern applications. In this article, we'll explore how to integrate Keycloak with Okta as an Identity Provider, creating a robust and scalable solution for user authentication.

What is Keycloak?

Keycloak is an open-source platform for Identity and Access Management (IAM). Developed by Red Hat, Keycloak offers comprehensive functionality for:

Single Sign-On (SSO): Allows users to log in once and access multiple applications
Identity Federation: Integration with external identity providers
User Management: Administrative interface for account and permission management
Standard Protocols: Complete support for OpenID Connect, OAuth 2.0, and SAML 2.0
Customization: Customizable interfaces and extensibility through SPIs (Service Provider Interfaces)

Keycloak is widely used by organizations that need a flexible authentication solution that can run on-premises or in cloud environments.

What is Okta?

Okta is a cloud-based Identity as a Service (IDaaS) platform, recognized as a leader in the IAM solutions market. Key features of Okta include:

Multi-Factor Authentication (MFA): Additional layers of security
Lifecycle Management: Automation of user provisioning and deprovisioning
Pre-built Integrations: Thousands of connectors for popular applications
Analytics and Monitoring: Detailed reports on authentication activities
Compliance: Adherence to standards like SOC 2, HIPAA, and GDPR

Okta is especially valued by companies seeking a managed solution with high availability and enterprise support.

Why Integrate Keycloak with Okta?

The integration between Keycloak and Okta offers the best of both worlds:

Keycloak Flexibility: Complete control over customizations and specific business logic
Okta Robustness: Reliable enterprise infrastructure and advanced security features
Hybrid Strategy: Ability to maintain some internal services while using cloud for others
Gradual Migration: Facilitates organizational transitions between different identity solutions

Step-by-Step Integration Guide

Prerequisites

Administrative access to Keycloak
Administrative account in Okta
Basic knowledge of OpenID Connect (OIDC)

Step 1: Application Configuration in Okta

Access the Okta Admin Console
Navigate to Applications > Create App Integration
Configure the following parameters:
- Sign-in method: OIDC - OpenID Connect
- Application type: Web Application
Define a descriptive name for the application
Save the configuration

After creation, you'll receive the essential credentials:

Client ID: Unique application identifier
Client Secret: Secret key for authentication

Step 2: Discovery Endpoint Location

The Discovery Endpoint is fundamental for OIDC integration:

In the Okta Admin Console, go to Security > API
Select the authorization server (usually "default")
Copy the Metadata URI - this will be your Discovery Endpoint

https://<your-okta-domain>.okta.com/oauth2/default/.well-known/openid-configuration

Step 3: Identity Provider Configuration in Keycloak

Access the Keycloak Admin Console
Select the appropriate realm
Navigate to Identity Providers
Click Add provider and select OpenID Connect v1.0
Configure the following fields:
- Alias: Internal identifier name (e.g., "okta")
- Client ID: Obtained from Okta in Step 1
- Client Secret: Obtained from Okta in Step 1
- Discovery Endpoint: Okta Metadata URI
- Trust Email: Enable this option to trust emails provided by Okta
Save the configuration

Advanced Scope Configuration

After creating the Identity Provider, you'll see an "Advanced" link in the interface. Click on it to access additional settings, including Default Scopes configuration.

In the Default Scopes field, you can specify which OAuth 2.0/OIDC scopes you want to request from Okta during authentication. The main scopes available in Okta include:

Standard OpenID Connect Scopes:

openid - Required for OIDC, allows access to ID token
profile - Access to basic profile information (name, surname, etc.)
email - Access to user's email address
address - Access to user's physical address
phone - Access to user's phone number

Okta-Specific Scopes:

groups - Access to groups the user belongs to
offline_access - Allows obtaining refresh tokens
device_sso - For device authentication

API Management Scopes (when configured):

okta.users.read - Read user information
okta.users.manage - User management
okta.groups.read - Read groups
okta.groups.manage - Group management
okta.apps.read - Read applications
okta.apps.manage - Application management

Configuration example:

openid profile email

Important note: Not all scopes are available by default. API Management-related scopes need to be configured in the Okta authorization server before being used.

Step 4: Redirect URL Configuration

In Keycloak, after saving the Identity Provider, copy the automatically generated Redirect URI
Return to the Okta Admin Console
Edit the application created in Step 1
In the Sign-in redirect URIs section, add the URL copied from Keycloak
Save the changes

Step 5: Integration Testing

Access your realm's login page in Keycloak
Verify that a "Login with Okta" button appears (or the configured name)
Click the button and test the authentication flow
Confirm that the user is correctly authenticated and redirected back

Advanced Configurations

Attribute Mapping

Configure mappings to synchronize user information:

{
  "name": "${ATTRIBUTE.name}",
  "email": "${ATTRIBUTE.email}",
  "given_name": "${ATTRIBUTE.given_name}",
  "family_name": "${ATTRIBUTE.family_name}"
}

Security Settings

Validate Signatures: Enable to verify JWT signatures
Use PKCE: Activate for enhanced security in authorization flows
Backchannel Logout: Configure for distributed logout

Groups and Roles

Configure automatic mapping of Okta groups to Keycloak roles through custom mappers.

Best Practices

Credential Security: Store Client Secrets securely
Monitoring: Implement detailed logs for auditing
Regular Testing: Validate integration periodically
Configuration Backup: Maintain backups of configurations
Documentation: Document specific customizations

Common Troubleshooting

Redirect URI Error

Problem: "Invalid redirect_uri"
Solution: Verify that the redirect URL in Okta exactly matches the one provided by Keycloak

Discovery Issues

Problem: Failed to discover endpoints
Solution: Confirm that the Metadata URI is accessible and correct

User Mapping

Problem: User information doesn't appear
Solution: Configure appropriate mappers in the Identity Provider

Conclusion

The integration between Keycloak and Okta provides a robust solution that combines flexibility and enterprise reliability. This configuration allows organizations to leverage the advantages of both platforms, creating a hybrid and efficient identity ecosystem.

With proper implementation of the steps described in this guide, developers can establish a solid integration that meets modern authentication needs while maintaining high standards of security and user experience.

Regular maintenance and continuous monitoring of this integration will ensure its optimized operation over time, providing a solid foundation for the growth and evolution of organizational identity systems.

The Secrets of Proxies: Intercepting and Controlling Objects in JavaScript

Ítalo Queiroz — Mon, 05 May 2025 11:17:58 +0000

Behind the scenes of JavaScript objects lies a powerful tool that allows you to intercept, modify, and control virtually any interaction with objects. Welcome to the world of Proxies.

Introduction: What Are Proxies?

In JavaScript, Proxies act as intermediaries for objects, allowing you to customize fundamental behaviors such as property reading, value assignment, enumeration, function invocation, and even operations with the new operator. Introduced in ES6 (ECMAScript 2015), Proxies remain underutilized by many developers, despite offering impressive possibilities.

A Proxy wraps a target object and defines traps that are triggered when specific operations are performed on the object. These traps allow you to intercept and customize JavaScript's default behavior.

Anatomy of a Proxy

The basic structure of a Proxy consists of two main components:

const proxy = new Proxy(target, handler);

Target: The original object to be wrapped by the proxy
Handler: An object containing the "traps" that define the customized behavior

Essential Traps

JavaScript offers 13 different traps, but let's focus on the most powerful ones:

1. get

The get trap intercepts property reads. It's triggered whenever you access an object property.

const handler = {
  get(target, prop, receiver) {
    console.log(`Accessing property: ${prop}`);
    return Reflect.get(target, prop, receiver);
  }
};

const user = { name: "Anna", age: 28 };
const userProxy = new Proxy(user, handler);

console.log(userProxy.name); 
// Output:
// Accessing property: name
// Anna

2. set

The set trap is triggered when values are assigned to properties.

const handler = {
  set(target, prop, value, receiver) {
    if (prop === 'age' && typeof value !== 'number') {
      throw new TypeError('Age must be a number');
    }
    console.log(`Setting ${prop} = ${value}`);
    return Reflect.set(target, prop, value, receiver);
  }
};

const userProxy = new Proxy({}, handler);

userProxy.name = "Charles"; // Setting name = Charles
userProxy.age = 30;         // Setting age = 30
try {
  userProxy.age = "thirty"; // Error!
} catch (e) {
  console.log(e.message);   // Age must be a number
}

3. apply

Intercepts function calls, allowing you to transform how a function is executed.

function add(a, b) {
  return a + b;
}

const handler = {
  apply(target, thisArg, args) {
    console.log(`Calling function with arguments: ${args}`);
    return Reflect.apply(target, thisArg, args);
  }
};

const addProxy = new Proxy(add, handler);
console.log(addProxy(5, 3));
// Output:
// Calling function with arguments: 5,3
// 8

4. construct

Intercepts the new operator, allowing you to control how objects are instantiated.

class Person {
  constructor(name) {
    this.name = name;
  }
}

const handler = {
  construct(target, args, newTarget) {
    console.log(`Creating new instance with: ${args}`);
    return Reflect.construct(target, args, newTarget);
  }
};

const PersonProxy = new Proxy(Person, handler);
const person = new PersonProxy("Daniel");
// Output: Creating new instance with: Daniel

Advanced Use Cases

1. Automatic Property Validation

One of the most powerful uses of Proxies is automatic property validation without polluting the original object's code.

function createValidator(schema) {
  return {
    set(target, prop, value) {
      if (!schema[prop]) {
        target[prop] = value;
        return true;
      }

      // Type validation
      if (schema[prop].type && typeof value !== schema[prop].type) {
        throw new TypeError(`${prop} must be of type ${schema[prop].type}`);
      }

      // Format validation (regex)
      if (schema[prop].pattern && !schema[prop].pattern.test(value)) {
        throw new Error(`${prop} does not match the expected pattern`);
      }

      // Minimum value validation
      if (schema[prop].min !== undefined && value < schema[prop].min) {
        throw new RangeError(`${prop} must be >= ${schema[prop].min}`);
      }

      target[prop] = value;
      return true;
    }
  };
}

const userSchema = {
  name: { type: "string" },
  email: { 
    type: "string", 
    pattern: /^[^\s@]+@[^\s@]+\.[^\s@]+$/
  },
  age: { 
    type: "number", 
    min: 18 
  }
};

const user = new Proxy({}, createValidator(userSchema));

user.name = "Laura";   // OK
user.age = 25;         // OK
// user.email = "invalid";  // Error: email does not match the expected pattern
// user.age = 15;           // Error: age must be >= 18

2. Reactive Objects (Vue.js Style)

Vue.js uses a technique similar to Proxies to create its reactivity system. Here's a simplified implementation:

function reactive(obj) {
  const observers = new Map();

  return new Proxy(obj, {
    get(target, prop, receiver) {
      const value = Reflect.get(target, prop, receiver);

      // Collect the current dependency if it exists
      if (activeEffect && typeof value !== 'object') {
        if (!observers.has(prop)) {
          observers.set(prop, new Set());
        }
        observers.get(prop).add(activeEffect);
      }

      return value;
    },

    set(target, prop, value, receiver) {
      const result = Reflect.set(target, prop, value, receiver);

      // Notify observers
      if (observers.has(prop)) {
        observers.get(prop).forEach(effect => effect());
      }

      return result;
    }
  });
}

// Simplified tracking system
let activeEffect = null;

function watchEffect(fn) {
  activeEffect = fn;
  fn();  // Execute the function to track dependencies
  activeEffect = null;
}

// Usage
const state = reactive({ counter: 0 });

watchEffect(() => {
  console.log(`The counter is: ${state.counter}`);
});

// Initial output: The counter is: 0
state.counter++;    // Output: The counter is: 1
state.counter += 2; // Output: The counter is: 3

3. Protection Against Unwanted Modifications

Proxies can protect critical objects against unwanted modifications, as well as detect unauthorized access:

function protectObject(obj, allowedOperations = {}) {
  return new Proxy(obj, {
    get(target, prop) {
      if (allowedOperations.read && !allowedOperations.read.includes(prop)) {
        console.warn(`Unauthorized read of property: ${prop}`);
        return undefined;
      }
      return target[prop];
    },

    set(target, prop, value) {
      if (allowedOperations.write && !allowedOperations.write.includes(prop)) {
        console.error(`Unauthorized attempt to modify: ${prop}`);
        return false;
      }
      target[prop] = value;
      return true;
    },

    deleteProperty(target, prop) {
      console.error(`Attempt to delete property: ${prop}`);
      return false;
    }
  });
}

const secureConfig = protectObject(
  { 
    debug: true, 
    apiKey: 'sk_12345',
    timeout: 30000 
  },
  {
    read: ['debug', 'timeout'],
    write: ['timeout']
  }
);

console.log(secureConfig.debug);   // true
console.log(secureConfig.apiKey);  // Warning and undefined
secureConfig.timeout = 60000;      // Allowed
secureConfig.apiKey = 'new_key';   // Error: Unauthorized attempt

4. Lazy Loading and Property Caching

We can use Proxies to implement lazy loading and caching of computationally expensive properties:

function lazyProperties(initializer) {
  const values = {};
  const computed = {};

  return new Proxy({}, {
    get(target, prop) {
      if (!(prop in values)) {
        // If the property hasn't been calculated yet
        if (prop in initializer) {
          console.log(`Calculating value for ${prop}...`);

          // Memoization: save the result for future use
          values[prop] = initializer[prop]();
          console.log(`Value calculated and cached.`);
        }
      }
      return values[prop];
    }
  });
}

// Usage:
const data = lazyProperties({
  expensiveValue: () => {
    // Simulating an expensive operation
    console.log('Executing time-consuming calculation...');
    let result = 0;
    for (let i = 0; i < 1000000; i++) {
      result += Math.random();
    }
    return result / 1000000;
  },
  anotherExpensiveValue: () => {
    // Another expensive operation
    return fetch('https://api.example.com/data').then(r => r.json());
  }
});

console.log(data.expensiveValue);  // Calculates the first time
console.log(data.expensiveValue);  // Uses cached value

Pitfalls and Performance Considerations

Although powerful, Proxies have some important limitations:

1. Performance Impact

Proxies add a layer of indirection that can affect performance, especially in high-frequency operations:

// Performance test
function testPerformance() {
  const obj = { value: 0 };
  const proxy = new Proxy(obj, {
    get: (target, prop) => Reflect.get(target, prop),
    set: (target, prop, value) => Reflect.set(target, prop, value)
  });

  console.time('Direct Object');
  for (let i = 0; i < 1000000; i++) {
    obj.value++;
  }
  console.timeEnd('Direct Object');

  console.time('Via Proxy');
  for (let i = 0; i < 1000000; i++) {
    proxy.value++;
  }
  console.timeEnd('Via Proxy');
}

testPerformance();
// Typical output:
// Direct Object: ~5ms
// Via Proxy: ~50ms

2. Behavior with Internal Methods

Internal methods and properties of an object can behave unexpectedly when accessed through a proxy:

class MyClass {
  constructor() {
    this.value = 42;
  }

  method() {
    return this.value;
  }
}

const instance = new MyClass();
const proxy = new Proxy(instance, {});

console.log(instance.method()); // 42
console.log(proxy.method());    // Can cause issues if 'this' is used internally

3. Proxies Are Not Transparent for instanceof

class Example {}
const proxy = new Proxy(new Example(), {});

console.log(proxy instanceof Example); // false - this might surprise you!

Integrating Proxies with Other Modern Features

Proxies with Reflect API

The Reflect API was introduced alongside Proxies and provides methods that correspond to the Proxy traps:

const object = { a: 1, b: 2 };
const proxy = new Proxy(object, {
  get(target, prop, receiver) {
    console.log(`Accessing ${prop}`);
    // Using Reflect.get instead of target[prop]
    return Reflect.get(target, prop, receiver);
  }
});

// Reflect also allows metaprogramming operations
console.log(Reflect.ownKeys(proxy)); // ['a', 'b']

Proxies with WeakMap for Private Data

We can combine Proxies with WeakMaps to create truly private properties:

const privateData = new WeakMap();

class SecureUser {
  constructor(name, password) {
    const data = { name, password, passwordAttempts: 0 };
    privateData.set(this, data);

    return new Proxy(this, {
      get(target, prop) {
        if (prop === 'name') {
          return privateData.get(target).name;
        }
        if (prop === 'checkPassword') {
          return password => {
            const data = privateData.get(target);
            data.passwordAttempts++;

            if (data.passwordAttempts > 3) {
              throw new Error('Account locked after multiple attempts');
            }

            return data.password === password;
          };
        }
        return target[prop];
      }
    });
  }
}

const user = new SecureUser('john', 'password123');
console.log(user.name);                // 'john'
console.log(user.checkPassword('wrong')); // false
console.log(user.checkPassword('wrong')); // false
console.log(user.checkPassword('wrong')); // false
// user.checkPassword('wrong');           // Error: Account locked
console.log(user.password);              // undefined - not accessible

Advanced Patterns with Proxies

Deep Proxying

To create fully reactive data structures, we need to apply proxies recursively:

function deepProxy(obj, handler) {
  if (typeof obj !== 'object' || obj === null) {
    return obj;
  }

  // Process arrays and objects recursively
  for (const key of Object.keys(obj)) {
    if (typeof obj[key] === 'object' && obj[key] !== null) {
      obj[key] = deepProxy(obj[key], handler);
    }
  }

  return new Proxy(obj, handler);
}

// Handler that logs all operations
const logHandler = {
  get(target, prop, receiver) {
    const value = Reflect.get(target, prop, receiver);
    console.log(`GET: ${prop}`);
    return value;
  },
  set(target, prop, value, receiver) {
    console.log(`SET: ${prop} = ${value}`);
    return Reflect.set(target, prop, value, receiver);
  }
};

const data = deepProxy({
  user: {
    profile: {
      name: 'Anna',
      contact: {
        email: 'anna@example.com'
      }
    },
    preferences: {
      theme: 'dark'
    }
  }
}, logHandler);

// Nested access tracked
data.user.profile.contact.email; // Logs all intermediate accesses

Pattern: Revocable Proxies for Temporary Access Control

JavaScript allows creating revocable proxies, useful for granting temporary access:

function createTemporaryAccess(obj, timeoutMs = 30000) {
  const { proxy, revoke } = Proxy.revocable(obj, {});

  setTimeout(() => {
    console.log('Access automatically revoked');
    revoke();
  }, timeoutMs);

  return proxy;
}

const sensitiveData = { apiKey: '12345', secret: 'confidential value' };
const temporaryAccess = createTemporaryAccess(sensitiveData, 5000);

// Immediate use works
console.log(temporaryAccess.apiKey); // '12345'

// After 5 seconds...
setTimeout(() => {
  try {
    console.log(temporaryAccess.apiKey);
  } catch (e) {
    console.log('Error:', e.message); // TypeError: Cannot perform 'get' on a proxy that has been revoked
  }
}, 6000);

Conclusion:

Proxies represent one of the most powerful additions to modern JavaScript, enabling advanced metaprogramming and transforming how we interact with objects. Frameworks like Vue.js already leverage this technology to create elegant reactive systems.

Final tips for effective use of Proxies:

Use sparingly: Proxies add complexity and can impact performance.
Consider the context: In critical high-performance applications, use Proxies only where the performance cost is acceptable.
Combine with other APIs: Reflect, WeakMap, and Classes work very well with Proxies.
Test thoroughly: Proxy behavior can be subtle, especially with inheritance and internal methods.

By mastering Proxies, you open the door to advanced programming patterns that can make your code more robust, secure, and expressive.

AbortController: The Superpower You Didn’t Know You Needed in JavaScript

Ítalo Queiroz — Thu, 20 Mar 2025 13:50:21 +0000

Have you ever found yourself in a situation where an HTTP request is stuck in limbo, an eventListener refuses to leave, or a timeout decides to wreak havoc on your app? If so, you need to meet AbortController. It’s like that friend who knows exactly when to say, “enough is enough,” and save the day.

Today, we’ll explore how AbortController can be used to cancel fetch requests, clean up eventListeners, and even manage timeouts. All with practical examples in plain JavaScript and React. And of course, with a touch of humor—because dev life is already complicated enough!

What is AbortController?

The AbortController is a native JavaScript interface that allows you to cancel asynchronous operations, such as HTTP requests, before they complete. It works hand-in-hand with AbortSignal, which is used to communicate the cancellation.

How does it work?

You create an AbortController.
Use the signal associated with it to "monitor" the asynchronous operation.
When you want to cancel, call the abort() method.

That’s it! Now, let’s see it in action.

1. Canceling Fetch Requests

Imagine you’re downloading a video, but the user decides to cancel the download. Without AbortController, the request would continue until completion, wasting resources. With it, you can stop the process midway.

let controller;
const url = "video.mp4";

const downloadBtn = document.querySelector(".download");
const abortBtn = document.querySelector(".abort");

downloadBtn.addEventListener("click", fetchVideo);

abortBtn.addEventListener("click", () => {
  if (controller) {
    controller.abort();
    console.log("Download canceled!");
  }
});

async function fetchVideo() {
  controller = new AbortController();
  const signal = controller.signal;

  try {
    const response = await fetch(url, { signal });
    console.log("Download complete:", response);
    // Process the video here
  } catch (err) {
    if (err.name === "AbortError") {
      console.log("Request aborted!");
    } else {
      console.error("Download error:", err);
    }
  }
}

Here, the "Cancel" button calls the abort() method on the controller, stopping the request. If the fetch has already completed, an AbortError is thrown.

2. Cleaning Up EventListeners

How many times have you forgotten to remove an eventListener, leaving it to consume memory and cause bugs? With AbortController, you can associate a signal with the listener and automatically remove it when needed.

const controller = new AbortController();

function handleClick(event) {
  console.log("Button clicked!", event);
}

// Add the listener with the AbortController's signal
document.querySelector("button").addEventListener("click", handleClick, { signal: controller.signal });
//Or you can pass the AbortController instance
//document.querySelector("button").addEventListener("click", handleClick, controller);

console.log("EventListener added!");

// After 5 seconds, remove the listener
setTimeout(() => {
  controller.abort();
  console.log("EventListener automatically removed!");
}, 5000);

With this, you’ll never have to worry about forgotten eventListeners again. The abort() method takes care of everything for you.

3. Managing Timeouts

And what about when a request takes too long? Instead of waiting forever, you can use AbortController to set a timeout and automatically cancel the operation.

const controller = new AbortController();
const timeoutId = setTimeout(() => {
  controller.abort();
  console.log("Timeout: request canceled!");
}, 3000); // Cancel after 3 seconds

fetch("https://api.example.com/data", { signal: controller.signal })
  .then(response => {
    clearTimeout(timeoutId); // Clear the timeout if the response arrives in time
    return response.json();
  })
  .then(data => console.log("Data received:", data))
  .catch(err => {
    if (err.name === "AbortError") {
      console.log("Request aborted due to timeout!");
    } else {
      console.error("Unexpected error:", err);
    }
  });

This ensures that slow requests don’t interfere with the user experience.

4. Using AbortController in React

In React, AbortController is especially useful for avoiding memory leaks when components unmount before a request is completed.

import React, { useState, useEffect } from "react";

function MyComponent() {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);

  useEffect(() => {
    const controller = new AbortController();
    const signal = controller.signal;

    const fetchData = async () => {
      setLoading(true);
      try {
        const response = await fetch("https://api.example.com/data", { signal });
        if (!response.ok) {
          throw new Error(`HTTP error: ${response.status}`);
        }
        const data = await response.json();
        setData(data);
      } catch (err) {
        if (err.name !== "AbortError") {
          setError(err);
        }
      } finally {
        setLoading(false);
      }
    };

    fetchData();

    return () => {
      controller.abort(); // Cancel the request when the component unmounts
    };
  }, []);

  if (loading) return <p>Loading...</p>;
  if (error) return <p>Error: {error.message}</p>;
  if (!data) return <p>No data available.</p>;

  return (
    <div>
      <h3>Data Received:</h3>
      <pre>{JSON.stringify(data, null, 2)}</pre>
    </div>
  );
}

export default MyComponent;

Here, the AbortController ensures that if the component unmounts before the request finishes, it will be canceled, preventing memory leaks.

Conclusion

The AbortController is a powerful and versatile tool that can greatly simplify the management of asynchronous operations in your code. Whether it’s canceling requests, cleaning up eventListeners, or managing timeouts, it helps keep your code cleaner, more efficient, and bug-free.

Query Optimization and Performance in DynamoDB: Partition Key and Sort Key

Ítalo Queiroz — Mon, 10 Feb 2025 23:06:49 +0000

Introduction

Amazon DynamoDB revolutionized the NoSQL database world with its flexible data model and high performance. At the core of its architecture, we find two fundamental concepts: Partition Key (PK) and Sort Key (SK). This article explores how these elements not only structure data but also significantly impact application performance and scalability.

Architectural Foundations

DynamoDB employs a distributed partitioning system where the Partition Key determines the physical location of data. This mechanism, developed by Amazon Web Services, evolved from the original Dynamo project, documented in the paper "Dynamo: Amazon's Highly Available Key-value Store" (DeCandia et al., 2007).

The formula for determining the partition is:

partition_number = hash(partition_key) mod N

Where N represents the total number of partitions available for the table.

Anatomy of Keys

Partition Key (PK)

The Partition Key serves as the primary identifier for data distribution. When an item is inserted, DynamoDB calculates a hash of the PK to determine which partition will store the item.

Sort Key (SK)

The Sort Key provides hierarchical ordering within each partition. It allows multiple items with the same PK, creating complex relationships and facilitating efficient queries.

Performance Analysis

Test Scenario

To demonstrate the benefits of a well-planned PK/SK structure, let's consider an e-commerce application with 1 million orders:

// Optimized structure
{
  PK: "CUSTOMER#123",
  SK: "ORDER#2024-02-10",
  orderTotal: 199.99,
  status: "delivered"
}

Performance Results

Based on AWS documented tests and community practical experiences:

Customer Queries:
- With PK/SK: ~10ms
- Without proper indexing: ~1000ms
Period Queries:
- With GSI (Global Secondary Index): ~20ms
- Full scan: >10000ms

Access Patterns and Optimizations

Example of Efficient Modeling

// Hierarchical access
{
  PK: "ORG#Tesla",
  SK: "DEPT#Engineering#EMP#123",
  name: "John Doe",
  role: "Senior Engineer"
}

This model enables efficient queries at multiple organizational levels using just a single index.

Common Anti-Patterns and Poor Modeling

Understanding what not to do is often as valuable as knowing best practices. Let's examine a problematic data modeling scenario that demonstrates common mistakes when structuring PK/SK relationships.

Example of Poor Modeling

Consider an e-commerce application where orders are modeled this way:

// Poor structure example
{
  PK: "2024-02-10", // Using date as PK
  SK: "ORDER#123",   // Using order ID as SK
  customerID: "CUST#789",
  orderTotal: 199.99,
  status: "delivered"
}

This design has several critical flaws:

Hot Partition Problem
- Using the date as PK means all orders from the same day will be stored in the same partition
- During high-traffic periods (like Black Friday), this creates a severe hot partition issue
- DynamoDB will throttle requests once partition capacity is exceeded
Limited Query Flexibility
- Cannot efficiently query all orders for a specific customer
- Requires expensive table scans to find customer orders
- No natural hierarchy in the data structure
Scalability Issues

   // Query to find all customer orders requires scanning
   {
     TableName: "Orders",
     FilterExpression: "customerID = :custId",
     ExpressionAttributeValues: {
       ":custId": "CUST#789"
     }
   }

Performance Impact of Poor Modeling

Let's compare the performance metrics of poor vs. optimal modeling:

Customer Order Lookup
- Poor Model: ~2000ms (requires scan)
- Optimal Model: ~10ms (direct query)
Daily Order Processing
- Poor Model: Frequent throttling due to hot partitions
- Optimal Model: Consistent sub-50ms response times
Storage Distribution
- Poor Model: Uneven partition utilization (>80% variation)
- Optimal Model: Near-uniform distribution (<10% variation)

Better Alternative

Here's how the same data should be modeled:

// Improved structure
{
  PK: "CUSTOMER#789",           // Distributes load across customers
  SK: "ORDER#2024-02-10#123",   // Maintains sortable hierarchy
  orderTotal: 199.99,
  status: "delivered"
}

// Create a GSI for date-based queries if needed
GSI1PK: "DATE#2024-02-10"
GSI1SK: "CUSTOMER#789#ORDER#123"

This improved structure:

Evenly distributes data across partitions
Enables efficient customer-specific queries
Maintains date-based access through GSI
Provides natural data hierarchy
Supports multiple access patterns efficiently

Quantifiable Benefits

Cost Reduction
- Up to 80% reduction in RCU (Read Capacity Units) consumption
- Elimination of unnecessary indexes
Latency Improvement
- 90% average reduction in response time for frequent queries
- Consistent performance even with data growth
Scalability
- Support for linear growth without performance degradation
- Uniform load distribution across partitions

Best Practices

To maximize the benefits of the PK/SK structure:

Distribute data uniformly across partitions
Avoid hot partitions by using high-cardinality PKs
Use key composition patterns (e.g., "TYPE#id")
Plan for your most common access patterns

Conclusion

DynamoDB's PK/SK structure, when well implemented, offers an exceptional balance between flexibility and performance. Documented gains in real cases demonstrate significant reductions in latency and operational costs.

References

DeCandia, G., et al. (2007). "Dynamo: Amazon's Highly Available Key-value Store". SOSP '07.
Amazon Web Services. (2024). "Amazon DynamoDB Developer Guide".
Sivasubramanian, S. (2012). "Amazon DynamoDB: A Seamlessly Scalable Non-relational Database Service". SIGMOD '12.
Vogels, W. (2012). "Amazon DynamoDB – a Fast and Scalable NoSQL Database Service Designed for Internet Scale Applications".

Web Security with Content Security Policy (CSP) and JavaScript

Ítalo Queiroz — Mon, 03 Feb 2025 23:10:32 +0000

Currently, I work for a major educational portal in England. Since we host numerous articles, books, and case studies, security is essential for us and, most importantly, for our customers who use the platform for research, purchasing new articles, and studying. Ensuring that our users are protected against attacks such as Cross-Site Scripting (XSS) is a top priority. To mitigate this risk, one of the most effective mechanisms is Content Security Policy (CSP), a powerful feature that we implement in our web applications.

What is Content Security Policy (CSP)?

CSP is a set of rules that restrict which resources (JavaScript, CSS, images, fonts, etc.) can be loaded on a web page. With this policy, you can prevent malicious code injection and significantly reduce the attack surface of your application.

How Does CSP Work?

CSP is defined through the HTTP header Content-Security-Policy. It specifies secure sources for scripts, stylesheets, images, and other resources.

Example of a CSP header:

Content-Security-Policy: default-src 'self'; script-src 'self' https://apis.google.com;

In this case, we are defining:

default-src 'self': Allows only resources from the same domain to be loaded.
script-src 'self' https://apis.google.com: Only local scripts and those from Google can be executed.

Content Security Policy Options

CSP allows defining rules for different types of resources:

default-src: Defines the default source for all resource types unless specific directives are provided.
script-src: Controls where scripts can be loaded from.
connect-src: Defines the allowed endpoints for AJAX connections, WebSockets, and APIs like Fetch and XHR.
style-src: Restricts the allowed stylesheets.
font-src: Specifies where fonts can be loaded from.
frame-src: Controls which domains can be loaded within iframes.
img-src: Defines the allowed sources for images.
object-src: Specifies where objects like Flash and plugins can be loaded from.

A more complete CSP header example:

Content-Security-Policy: default-src 'self'; script-src 'self' https://apis.google.com; style-src 'self' https://fonts.googleapis.com; img-src 'self' https://images.example.com; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://api.example.com; frame-src 'none'; object-src 'none';

Configuring CSP in Apache

If your web server is Apache, you can configure CSP by adding the following directive to the .htaccess or httpd.conf file:

<IfModule mod_headers.c>
    Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://apis.google.com; style-src 'self' https://fonts.googleapis.com; img-src 'self' https://images.example.com; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://api.example.com; frame-src 'none'; object-src 'none';"
</IfModule>

This ensures that all requests are filtered according to the defined security rules.

Configuring CSP in Nginx

If you are using Nginx, you can enable CSP by adding the following directive to your server configuration:

server {
    listen 80;
    server_name example.com;

    add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://apis.google.com; style-src 'self' https://fonts.googleapis.com; img-src 'self' https://images.example.com; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://api.example.com; frame-src 'none'; object-src 'none';" always;
}

This configuration ensures that all resources follow the specified security rules.

Securing Your Application with CSP and JavaScript

1. Blocking Inline Scripts

CSP can block inline scripts, preventing malicious code from being injected into HTML elements. To do this, we should avoid using:

<script>alert('XSS!');</script>

And configure CSP to prevent inline scripts:

Content-Security-Policy: script-src 'self';

If you need to execute inline scripts, you can use hashes or nonces to allow only specific scripts.

2. Using Nonces to Allow Specific Scripts

A nonce (unique number per request) allows only signed scripts to be executed:

Content-Security-Policy: script-src 'nonce-random123';

In HTML:

<script nonce="random123">console.log('Allowed by CSP');</script>

3. Preventing Untrusted Resource Loading

By restricting external sources, we ensure that only trusted resources are loaded. A secure CSP might be:

Content-Security-Policy: default-src 'self'; img-src 'self' https://images.example.com; font-src 'self' https://fonts.googleapis.com;

Here, we are allowing only images and fonts from specific domains.

Monitoring and Testing CSP

To test if your application is protected, you can configure CSP in report-only mode:

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

This allows monitoring violations without blocking resources.

Conclusion

Implementing Content Security Policy is one of the most crucial steps in ensuring the security of modern web applications. With a well-configured CSP, you significantly reduce the risk of XSS attacks and improve protection against malicious code injections.

If you haven’t implemented CSP on your website yet, now is the time to start!

Keeping JavaScript Dependencies Secure: An Essential Guide

Ítalo Queiroz — Mon, 27 Jan 2025 15:26:23 +0000

In modern web applications, security extends far beyond the code we write. With JavaScript projects relying on hundreds of third-party packages, keeping these dependencies updated and vulnerability-free has become a crucial aspect of secure software development.

Currently, on my squad, we use vulnerability information to guide our update prioritization strategy. Our focus remains primarily on addressing high and critical issues in production dependencies, as these pose the most immediate risks to our systems. By sharing our approach and experiences through this guide, I aim to help you make informed decisions about your own project's security and establish effective update workflows. Understanding when and what to update isn't just about following best practices—it's about developing a practical, risk-based approach that protects your applications while maintaining development efficiency.

Why Care About Dependency Updates?

Consider building a house: you don't just worry about the quality of your materials, but also about the integrity of every component you use, from locks to electrical installations. Similarly, each dependency in your project is like a component of that house, and a single vulnerability can compromise the entire structure.

In 2021, a Snyk study revealed that 84% of web application vulnerabilities came from third-party dependencies. This means that even with impeccable code, your application might be exposed to significant risks through the libraries it uses.

How to Identify Vulnerabilities in Your Project

NPM provides a powerful integrated security analysis tool: npm audit. Let's explore how to use it effectively:

Running a Basic Audit

To perform a basic security check, run in your terminal:

npm audit

This command will analyze your package-lock.json file and report any vulnerabilities found. A typical output looks like this:

# npm audit report

axios  <0.21.1
Severity: high
Prototype Pollution in axios - https://github.com/advisories/GHSA-7rjr-3q55-vv33
fix available via `npm audit fix`
node_modules/axios
  react-scripts  *
  depends on axios@0.19.2
  node_modules/react-scripts

1 high severity vulnerability

Understanding the Vulnerability Report

The report classifies vulnerabilities into different levels:

low: Minimal impact, usually non-critical
moderate: Potential to cause problems under certain circumstances
high: Serious vulnerabilities that should be addressed quickly
critical: Severe flaws requiring immediate attention

Fixing Found Vulnerabilities

To automatically fix found vulnerabilities, you can use:

npm audit fix

For more complex cases that might cause breaking changes:

npm audit fix --force

⚠️ Warning: Using --force should be done with caution as it may break your application's compatibility.

Deep Dive into Dependency Investigation

Sometimes a vulnerability alert requires more than just a quick fix. A thorough dependency investigation can reveal opportunities for both security improvements and codebase modernization. This investigation process involves several key aspects that might not be immediately obvious from security reports alone.

When investigating a dependency, consider its entire ecosystem: recent releases, community activity, maintenance status, and most importantly, compatibility with your project. This comprehensive review helps you make an informed decision between a simple patch update and a major version migration. For instance, if you're dealing with a vulnerability in an older version of Express.js, you might discover that upgrading to the latest major version not only resolves security issues but also brings performance improvements and new features that could benefit your application.

Testing Strategy for Safe Updates

Before implementing any dependency updates in production, it's crucial to validate them through a comprehensive testing strategy. Here's a methodical approach to ensure safe updates:

Unit Tests: Verify that individual components still function correctly with the updated dependencies. Pay special attention to components that directly interact with the updated packages.
Integration Tests: Ensure that different parts of your application still work together seamlessly. This is particularly important when updating packages that handle data flow or state management.
End-to-End (E2E) Tests: Run complete user journey tests to catch any issues that might only appear in fully integrated scenarios.
Regression Testing: This crucial step helps identify if the updates have inadvertently affected existing functionality. Consider implementing:
- Automated regression test suites
- Manual testing of critical user paths
- Performance regression testing, especially for core functionality

Real-World Example

Consider a recent case where updating a React-based UI library required investigation:

// Old version with vulnerability
"react-ui-library": "^2.5.0"  // Known XSS vulnerability

// After investigation, we found two potential paths:
// Option 1: Patch update
"react-ui-library": "^2.5.8"  // Patches XSS but keeps same API

// Option 2: Major version upgrade
"react-ui-library": "^3.0.0"  // Completely new API, better security model

In this case, a proper investigation revealed that while the patch update (Option 1) would fix the immediate security concern, the major version upgrade (Option 2) offered a more robust security model and better long-term maintainability. However, this decision could only be made after thorough testing and evaluation of the migration effort required.

Best Practices for Continuous Maintenance

Maintain a Change Log

Document all significant dependency updates, including:

Update date
Updated packages
Reason for update
Impact on existing functionalities

Configure Automatic Alerts

Use tools like GitHub Dependabot or Snyk to receive automatic alerts about new vulnerabilities.

Additional Recommended Tools

Beyond npm audit, consider using:

Jest Security Check: For projects using Jest as the testing framework
OWASP Dependency-Check: A tool that can be integrated into your CI/CD pipeline

Conclusion

Keeping your dependencies updated isn't just about having the latest features—it's a critical security necessity. Establish a regular update and audit process, and treat it as a fundamental part of your project's lifecycle.

Remember: in software security, prevention is always better than remediation. A small regular time investment in dependency maintenance can prevent major headaches in the future.

Migrating a Legacy Project from Vue CLI to Vite

Ítalo Queiroz — Tue, 21 Jan 2025 14:18:52 +0000

Recently, a ticket was added to our sprint with the goal of reducing packages with critical and high vulnerabilities in a legacy project. The task involved migrating a Vue 2 project using Vue CLI as the build tool to Vite.

This was an excellent opportunity to modernize the stack and leverage the performance benefits Vite offers. In this article, I'll share the main steps I followed to complete the migration.

What is Vite?

Vite (pronounced "veet") is a build tool designed to provide a faster (and it’s really fast) and leaner development experience for modern web projects.

With Vite, you get significantly shorter build times, a blazing-fast dev server, and a simplified configuration process.

Migration Steps

1. Updating the `package.json`

The first step was removing all Vue CLI dependencies from the project. This included Babel-related packages, the babel.config.js configuration file, and the core-js dependency.

//package.json
"@vue/cli-plugin-babel": "~5.0.8", //remove
"@vue/cli-plugin-e2e-nightwatch": "~5.0.8", //remove
"@vue/cli-plugin-eslint": "~5.0.8", //remove
"@vue/cli-plugin-unit-jest": "~5.0.8", //remove
"@vue/cli-service": "~5.0.8", //remove

"core-js": "^3.6.4", //remove
"@babel/core": "^7.8.4", //remove
"babel-core": "^7.0.0-bridge.0", //remove
"babel-jest": "^25.1.0", //remove

If your ESLint configuration uses "babel-eslint" as the parser, you’ll need to replace it.

//package.json
"babel-eslint": "^10.0.3", //remove

I migrated my ESLint configuration from .eslintrc to the modern eslint.config.mjs format and updated ESLint to version 8, which I highly recommend.

npm install eslint@8 eslint-plugin-vue@8 --save-dev

npx @eslint/migrate-config .eslintrc.js

After cleaning up these dependencies, I added Vite and a plugin for Vue integration:

npm install vite @vitejs/plugin-vue2 --save-dev

2. Setting Up Vite

Like many other libraries, Vite uses a configuration file (vite.config.js) at the root of the project to define build and development options. Here's a simple starting point:

import { defineConfig } from 'vite'
import vue2 from '@vitejs/plugin-vue2'

export default defineConfig({
  plugins: [vue2()],
  resolve: {
    extensions: ['.mjs', '.js', '.ts', '.jsx', '.tsx', '.json', '.vue'],
    alias: {
      '@': fileURLToPath(new URL('./src', import.meta.url))
    }
  }
});

3. Moving and Updating `index.html`

In Vue CLI, the index.html file is typically located in the public folder. However, Vite expects it at the root of the project. Move the file to the root and update any path references as needed.

mv public/index.html index.html

<!--remove-->
<link rel="icon" href="<%= BASE_URL %>favicon.ico" />
<!--add-->
<link rel="icon" href="/favicon.ico" />

<!--add-->
<script type="module" src="/src/main.js"></script>

The main.js is included because we're no longer automatically injecting.

4. Updating Environment Variables

Vite handles environment variables differently. Ensure you update or create .env files and prefix all variables you want to expose with VITE_. For example:

VITE_API_URL=https://api.example.com

// router/index.js
//remove
base: process.env.BASE_URL, 
//add
base: import.meta.env.BASE_URL,

5. Updating the Scripts

Lastly, I updated the scripts in the package.json to use the Vite binary instead of Vue CLI. Here's how they look now:

//from
"scripts": {
  "serve": "vue-cli-service serve --port 8084",
  "dev": "npm run serve",
  "build": "vue-cli-service build",
  "test:unit": "vue-cli-service test:unit",
  "test:e2e": "vue-cli-service test:e2e --headless",
  "lint": "vue-cli-service lint",
  "test": "npm run test:unit && npm run test:e2e"
},


//to
"scripts": {
  "serve": "vite --port 8084",
  "dev": "npm run serve",
  "build": "vite build",
  "test:e2e": "nightwatch --headless",
  "test:unit": "vitest --run",
  "test": "npm run test:unit && npm run test:e2e",
  "lint": "eslint ."
},

With these changes, you can now run your Vue 2 project using Vite and enjoy all the benefits it brings, especially improved build performance.

Next Steps

In my next article, I'll share how I enabled Nightwatch without the Vue CLI plugin and migrated Jest to Vitest. Stay tuned!

If you have any questions or want to share your own experiences with Vite, feel free to leave a comment! 🚀