# Security Best Practices Standards for WebSockets

This document outlines the security best practices for WebSockets development. It's intended to guide developers in building secure and robust WebSocket applications and serves as a reference for AI coding assistants.

## 1. Input Validation and Sanitization

### 1.1. Standard: Validate all incoming data

**Do This:** Implement thorough validation on all data received from WebSocket clients.

**Don't Do This:** Assume incoming data is safe or conforms to expected formats.

**Why:** Prevents injection attacks, data corruption, and unexpected application behavior.

**Explanation:** Always validate the type, format, length, and allowable values of incoming data. This includes verifying that JSON structures are well-formed and that strings do not contain malicious characters.

**Code Example (Node.js with "ws" and validator.js):**

"""javascript

const WebSocket = require('ws');

const validator = require('validator');

const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', ws => {

ws.on('message', message => {

try {

const data = JSON.parse(message);

// Validate the data

if (typeof data.username !== 'string' || !validator.isLength(data.username, { min: 3, max: 20 })) {

ws.send(JSON.stringify({ error: 'Invalid username' }));

return;

}

if (typeof data.message !== 'string' || !validator.isLength(data.message, { min: 1, max: 200 })) {

ws.send(JSON.stringify({ error: 'Invalid message' }));

return;

}

const sanitizedUsername = validator.escape(data.username);

const sanitizedMessage = validator.escape(data.message);

console.log("Received: ${sanitizedUsername}: ${sanitizedMessage}");

// Process the data

wss.clients.forEach(client => {

if (client !== ws && client.readyState === WebSocket.OPEN) {

client.send(JSON.stringify({ username: sanitizedUsername, message: sanitizedMessage }));

}

});

} catch (e) {

console.error("Invalid JSON:", e);

ws.send(JSON.stringify({ error: 'Invalid JSON format' }));

}

});

ws.on('close', () => {

console.log('Client disconnected');

});

console.log('WebSocket server started on port 8080');

"""

**Anti-Pattern:** Directly using client-provided data without validation.

"""javascript

// BAD EXAMPLE: Vulnerable to injection if "data.message" contains HTML

ws.on('message', message => {

const data = JSON.parse(message);

wss.clients.forEach(client => {

client.send("${data.message}"); //Directly embedding client data

});

"""

### 1.2. Standard: Use allow-lists for data validation

**Do This:** Define the specific allowed values and formats.

**Don't Do This:** Rely on block-lists to prevent malicious inputs.

**Why:** Block-lists are often incomplete and can be bypassed. Allow-lists provide a more secure and predictable validation.

**Explanation:** Instead of trying to identify and block all possible malicious inputs, define what valid inputs look like and reject anything that doesn't conform. For example, use regular expressions to validate email addresses or phone numbers, or enforce a limited set of allowable characters for usernames.

**Code Example (Python with "websockets"):**

"""python

import asyncio

import websockets

import re

ALLOWED_CHARACTERS = r"^[a-zA-Z0-9_]+$"

async def echo(websocket):

async for message in websocket:

if not re.match(ALLOWED_CHARACTERS, message):

await websocket.send("Invalid input: Only alphanumeric characters and underscores allowed.")

else:

await websocket.send(f"Received: {message}")

async def main():

async with websockets.serve(echo, "localhost", 8765):

await asyncio.Future() # run forever

if __name__ == "__main__":

asyncio.run(main())

"""

**Anti-Pattern:** Using blacklist approach

"""python

# BAD EXAMPLE: Using a blacklist is vulnerable to evasion.

BLACKLIST = ["

Cline

This guide explains how to effectively use .clinerules with Cline, the AI-powered coding assistant.

Overview

The .clinerules file is a powerful configuration file that helps Cline understand your project's requirements, coding standards, and constraints. When placed in your project's root directory, it automatically guides Cline's behavior and ensures consistency across your codebase.

Key Concepts

Purpose of .clinerules

Defines project-specific guidelines and requirements
Enforces consistent coding standards
Establishes documentation practices
Sets testing and quality requirements
Configures error handling preferences

File Location

Place the .clinerules file in your project's root directory. Cline automatically detects and follows these rules for all files within the project.

Rule Structure

1. Project Overview

# Project Overview
project:
  name: 'Your Project Name'
  description: 'Brief project description'
  stack:
    - technology: 'Framework/Language'
      version: 'X.Y.Z'
    - technology: 'Database'
      version: 'X.Y.Z'

2. Code Standards

# Code Standards
standards:
  style:
    - 'Use consistent indentation (2 spaces)'
    - 'Follow language-specific naming conventions'
  documentation:
    - 'Include JSDoc comments for all functions'
    - 'Maintain up-to-date README files'
  testing:
    - 'Write unit tests for all new features'
    - 'Maintain minimum 80% code coverage'

3. Security Rules

# Security Guidelines
security:
  authentication:
    - 'Implement proper token validation'
    - 'Use environment variables for secrets'
  dataProtection:
    - 'Sanitize all user inputs'
    - 'Implement proper error handling'

Best Practices

Writing Effective Rules

Be Specific
- Use clear, actionable language
- Provide examples where helpful
- Define measurable criteria
Maintain Organization
- Group related rules together
- Use consistent formatting
- Keep critical rules at the top
Regular Updates
- Review rules periodically
- Update based on team feedback
- Document changes in version control

Common Patterns

# Common Patterns Example
patterns:
  components:
    - pattern: 'Use functional components by default'
    - pattern: 'Implement error boundaries for component trees'
  stateManagement:
    - pattern: 'Use React Query for server state'
    - pattern: 'Implement proper loading states'

Integration with Development Workflow

Using with Version Control

Commit the Rules
- Include .clinerules in version control
- Document rule changes in commit messages
- Review rule changes as part of PR process
Team Collaboration
- Discuss rule changes with team
- Maintain changelog for rule updates
- Ensure all team members understand rules

Troubleshooting

Common Issues

Rules Not Being Applied
- Verify file location (must be in root directory)
- Check file formatting
- Ensure Cline has access to the file
Conflicting Rules
- Review rule hierarchy
- Resolve conflicts explicitly
- Document rule precedence
Performance Considerations
- Keep rules concise and focused
- Avoid overly complex rule structures
- Regular cleanup of obsolete rules

Examples

Basic Project Setup

# Basic .clinerules Example
project:
  name: 'Web Application'
  type: 'Next.js Frontend'
  standards:
    - 'Use TypeScript for all new code'
    - 'Follow React best practices'
    - 'Implement proper error handling'

testing:
  unit:
    - 'Jest for unit tests'
    - 'React Testing Library for components'
  e2e:
    - 'Cypress for end-to-end testing'

documentation:
  required:
    - 'README.md in each major directory'
    - 'JSDoc comments for public APIs'
    - 'Changelog updates for all changes'

Advanced Configuration

# Advanced .clinerules Example
project:
  name: 'Enterprise Application'
  compliance:
    - 'GDPR requirements'
    - 'WCAG 2.1 AA accessibility'

architecture:
  patterns:
    - 'Clean Architecture principles'
    - 'Domain-Driven Design concepts'

security:
  requirements:
    - 'OAuth 2.0 authentication'
    - 'Rate limiting on all APIs'
    - 'Input validation with Zod'

Security Best Practices Standards for WebSockets