# Security Best Practices Standards for Monorepo

This document outlines security best practices for Monorepo development. It serves as a guide for developers to write secure code, protect against common vulnerabilities, and implement secure coding patterns within a Monorepo architecture. Adherence to these standards is crucial for maintaining the integrity, confidentiality, and availability of applications built with Monorepo.

## 1. Input Validation and Sanitization

### Standard

All external inputs MUST be validated and sanitized before processing within any module/package in the Monorepo. This includes inputs from users, databases, APIs, and other sources.

* **Do This:** Use input validation libraries specific to your technology stack (e.g., "validator.js" for Node.js) and define strict validation rules. Sanitize inputs to remove potentially malicious characters or code.

* **Don't Do This:** Trust that input is safe or rely solely on client-side validation.

### Why It Matters

Failing to validate and sanitize inputs can lead to various vulnerabilities, including SQL injection, cross-site scripting (XSS), command injection, and path traversal attacks.

### Code Examples

**Node.js (Express.js) with "validator.js":**

"""javascript

const express = require('express');

const { body, validationResult } = require('express-validator');

const validator = require('validator');

const app = express();

app.use(express.json());

app.post('/user', [

// Validate and sanitize the request body

body('email').isEmail().normalizeEmail(),

body('password').isLength({ min: 8 }).trim().escape(),

body('username').matches(/^[a-zA-Z0-9]+$/).trim().escape(),

], (req, res) => {

const errors = validationResult(req);

if (!errors.isEmpty()) {

return res.status(400).json({ errors: errors.array() });

}

// Input is validated and sanitized, proceed with processing

const { email, password, username } = req.body;

console.log("Creating user with validated data: Email=${email}, Username=${username}");

res.send('User created successfully');

});

const PORT = process.env.PORT || 3000;

app.listen(PORT, () => {

console.log("Server is running on port ${PORT}");

});

"""

**Explanation:**

* "express-validator" middleware is used to validate and sanitize request body parameters.

* "isEmail()": Ensures the email is in a valid format.

* "normalizeEmail()": Normalizes the email address (e.g., converts to lowercase).

* "isLength({ min: 8 })": Requires the password to be at least 8 characters long.

* "trim()": Removes whitespace from the beginning and end of the input.

* "escape()": Escapes HTML characters to prevent XSS attacks.

* "matches(/^[a-zA-Z0-9]+$/)": Ensures the username contains only alphanumeric characters.

* Error handling is implemented using "validationResult".

### Anti-Patterns

"""javascript

// Anti-pattern: Directly using user input without validation or sanitization

app.get('/items/:id', (req, res) => {

const itemId = req.params.id; // NO VALIDATION

// Potentially vulnerable query

db.query("SELECT * FROM items WHERE id = ${itemId}", (err, result) => {

if (err) {

console.error(err);

return res.status(500).send('Database error');

}

res.json(result);

});

"""

**Explanation:**

The above code is susceptible to SQL injection because "itemId" from the request parameters is directly used in the SQL query without any validation or sanitization. An attacker could potentially inject malicious SQL code into the "itemId" parameter, leading to unauthorized data access or modification.

## 2. Authentication and Authorization

### Standard

Robust authentication and authorization mechanisms MUST be implemented to protect resources within the Monorepo.

* **Do This:** Use strong password hashing algorithms (e.g., bcrypt), multi-factor authentication (MFA) where possible, and role-based access control (RBAC). Utilize established libraries and frameworks for authentication and authorization.

* **Don't Do This:** Store passwords in plaintext, use weak or outdated hashing algorithms, or rely solely on client-side authorization. Avoid hardcoding credentials.

### Why It Matters

Proper authentication and authorization prevent unauthorized access to sensitive data and functionality.

### Code Examples

**Node.js (Express.js) with JWT and bcrypt:**

"""javascript

const express = require('express');

const bcrypt = require('bcrypt');

const jwt = require('jsonwebtoken');

const app = express();

app.use(express.json());

// In-memory user storage (in a real application, use a database)

const users = [];

// Registration

app.post('/register', async (req, res) => {

try {

const hashedPassword = await bcrypt.hash(req.body.password, 10);

const user = { name: req.body.name, password: hashedPassword };

users.push(user);

res.status(201).send('User registered');

} catch {

res.status(500).send();

}

});

// Login

app.post('/login', async (req, res) => {

const user = users.find(user => user.name === req.body.name);

if (user == null) {

return res.status(400).send('Cannot find user');

}

try {

if (await bcrypt.compare(req.body.password, user.password)) {

// Generate JWT token

const accessToken = jwt.sign({ name: user.name }, 'YOUR_SECRET_KEY', { expiresIn: '15m' }); // REPLACE WITH SECURE, ENVIRONMENT-SPECIFIC KEY

res.json({ accessToken: accessToken });

} else {

res.status(401).send('Not Allowed');

}

} catch {

res.status(500).send();

}

});

// Middleware to authenticate JWT token

function authenticateToken(req, res, next) {

const authHeader = req.headers['authorization'];

const token = authHeader && authHeader.split(' ')[1];

if (token == null) return res.sendStatus(401);

jwt.verify(token, 'YOUR_SECRET_KEY', (err, user) => { // REPLACE WITH SECURE, ENVIRONMENT-SPECIFIC KEY

if (err) return res.sendStatus(403);

req.user = user;

next();

});

}

// Secured route

app.get('/protected', authenticateToken, (req, res) => {

res.json({ message: "Welcome, ${req.user.name}!" });

});

const PORT = process.env.PORT || 3000;

app.listen(PORT, () => {

console.log("Server is running on port ${PORT}");

});

"""

**Explanation:**

* **bcrypt:** Used to securely hash passwords before storing them. A salt is automatically generated and included in the hash. A work factor of 10 is used, offering a reasonable balance between security and performance.

* **JWT (JSON Web Tokens):** Used to create access tokens for authenticated users allowing access to protected routes.

* **"authenticateToken" middleware:** Verifies the JWT token and protects sensitive routes.

* **Important:** Replace "'YOUR_SECRET_KEY'" with a strong, randomly generated secret key stored securely in an environment variable.

### Anti-Patterns

"""javascript

// Anti-pattern: Storing passwords in plaintext

app.post('/register', (req, res) => {

const password = req.body.password; // Storing plaintext password

//...

});

// Anti-pattern: Weak authentication mechanism

app.get('/admin', (req, res) => {

const isAdmin = req.query.admin === 'true'; // Insecure authentication

if (isAdmin) {

// Allows access

}

});

"""

Storing passwords in plaintext is a critical security vulnerability. Using query parameters for authentication is easily manipulated.

## 3. Secrets Management

### Standard

Secrets (API keys, database passwords, encryption keys, etc.) MUST be stored securely and never hardcoded in the source code of Monorepo packages.

* **Do This:** Use a dedicated secrets management solution (e.g., HashiCorp Vault, AWS Secrets Manager), environment variables, or encrypted configuration files. Apply the principle of least privilege to secret access. Rotate secrets regularly.

* **Don't Do This:** Hardcode secrets directly into the code, check them into version control, or log them.

### Why It Matters

Exposing secrets can lead to unauthorized access to systems, data breaches, and other severe security incidents.

### Code Examples

**Node.js with Environment Variables (using "dotenv"):**

"""javascript

require('dotenv').config(); // Load environment variables from .env file

const express = require('express');

const app = express();

const apiKey = process.env.API_KEY; // Access secret from environment variable

const dbPassword = process.env.DB_PASSWORD;

app.get('/data', (req, res) => {

// Use apiKey and dbPassword securely

console.log("Using API Key: ${apiKey.substring(0,4)}..."); // Logs the first four characters of the API key; better than logging the entire value

// ... your code to access date from db

res.send('Data retrieved');

});

const PORT = process.env.PORT || 3000;

app.listen(PORT, () => {

console.log("Server is running on port ${PORT}");

});

"""

**Explanation:**

* ".env" file (which should be added to ".gitignore") stores sensitive configuration data.

* "dotenv" package loads the environment variables from the ".env" file into "process.env".

* Secrets are accessed using "process.env.VARIABLE_NAME".

### Anti-Patterns

"""javascript

// Anti-pattern: Hardcoding API key

const apiKey = 'YOUR_API_KEY'; // DO NOT DO THIS

// Anti-pattern: Logging secrets

console.log('Database password:', dbPassword); // DO NOT DO THIS

"""

Hardcoding secrets directly within source code is a critical error and exposes the application to significant risk. Logging Secrets allows them to be captured and exposed.

## 4. Dependency Management

### Standard

Monorepo dependency management MUST be carefully controlled to avoid vulnerabilities introduced through third-party libraries.

* **Do This:** Use a package manager (e.g., npm, yarn, pnpm) with lockfiles to ensure consistent dependency versions. Regularly audit dependencies for known vulnerabilities using tools like "npm audit" or "yarn audit" and address identified issues promptly. Prefer well-maintained and reputable libraries. Use a dependency management tool like Dependabot, Snyk, or GitHub's automated security updates.

* **Don't Do This:** Use outdated or unmaintained libraries, ignore security audit warnings, or blindly update dependencies without testing.

### Why It Matters

Third-party libraries can contain vulnerabilities that can be exploited to compromise the entire application.

### Code Examples

**Using npm audit:**

"""bash

npm audit

npm audit fix # attempts to automatically fix vulnerabilities

"""

**Using yarn audit:**

"""bash

yarn audit

yarn audit fix # attempts to automatically fix vulnerabilities

"""

**Explanation:**

* "npm audit" and "yarn audit" scan the project's dependencies for known vulnerabilities and provide recommendations for remediation.

* "npm audit fix" and "yarn audit fix" attempt to automatically update vulnerable dependencies to patched versions (use with caution - test thoroughly!).

### Anti-Patterns

"""javascript

// Anti-pattern: Using an outdated library with known vulnerabilities

const someOutdatedLibrary = require('some-outdated-library'); // Likely has known security issues

// Anti-pattern: Ignoring audit warnings

// After running 'npm audit' and seeing warnings, ignoring them and proceeding

"""

Ignoring security audits can leave your application vulnerable and susceptible to known exploits within the outdated or vulnerable libraries. Continuously monitor dependency health

## 5. Error Handling and Logging

### Standard

Proper error handling and logging MUST be implemented to provide visibility into application behavior while avoiding exposing sensitive information.

* **Do This:** Implement structured logging using a logging library (e.g., Winston, Morgan). Log essential events (e.g., authentication attempts, authorization failures, unexpected errors). Avoid logging sensitive data (e.g., passwords, API keys, personally identifiable information (PII)). Implement centralized logging.

* **Don't Do This:** Log error details directly to users, ignore errors, or use "console.log" for production logging.

### Why It Matters

Poor error handling can expose internal system details to attackers, while inadequate logging hinders incident response and security investigations.

### Code Examples

**Node.js with Winston:**

"""javascript

const express = require('express');

const winston = require('winston');

const app = express();

// Configure Winston logger

const logger = winston.createLogger({

level: 'info',

format: winston.format.json(),

transports: [

new winston.transports.Console(),

new winston.transports.File({ filename: 'error.log', level: 'error' }),

new winston.transports.File({ filename: 'combined.log' }),

});

app.get('/error', (req, res) => {

try {

throw new Error('Simulated error');

} catch (error) {

logger.error({ message: 'Error occurred', error: error.message, stack: error.stack });

res.status(500).send('Internal server error'); // Display generic message to user

}

});

app.get('/info', (req, res) => {

logger.info({ message: 'Accessing info endpoint' });

res.send('Info endpoint accessed');

});

const PORT = process.env.PORT || 3000;

app.listen(PORT, () => {

logger.info("Server is running on port ${PORT}");

console.log("Server is running on port ${PORT}");

});

"""

**Explanation:**

* Winston is used for structured logging.

* Logs are written to the console and to files.

* Different log levels are used (e.g., "info", "error").

* Error details are logged, but a generic error message is shown to the user. Avoid showing stack traces directly to the client.

### Anti-Patterns

"""javascript

// Anti-pattern: Exposing error details to users

app.get('/error', (req, res) => {

try {

throw new Error('Detailed error message');

} catch (error) {

res.status(500).send(error.message); // Exposes internal error message

}

});

// Anti-pattern: Using console.log for production logging

console.log('User logged in'); // Inadequate for production, lacks context and control

"""

It is bad practice to expose detailed error messages or internal system details to end-users. It may allow threat actors to infer or discover further exploitable information.

## 6. Data Encryption

### Standard

Sensitive data MUST be encrypted both in transit and at rest.

* **Do This:** Use HTTPS for all network communication. Use encryption libraries (e.g., OpenSSL) to encrypt data stored in databases or files. Consider field-level encryption for highly sensitive data. Use a key management service to manage encryption keys.

* **Don't Do This:** Store sensitive data in plaintext, use outdated encryption algorithms, or hardcode encryption keys.

### Why It Matters

Encryption protects data from unauthorized access, even if a system is compromised.

### Code Examples

**Node.js with HTTPS and "crypto" library:**

"""javascript

const express = require('express');

const https = require('https');

const fs = require('fs');

const crypto = require('crypto'); // Import the crypto module

const app = express();

// Generate a secure encryption key (store securely)

const encryptionKey = crypto.randomBytes(32);

const iv = crypto.randomBytes(16);

function encrypt(text) {

const cipher = crypto.createCipheriv('aes-256-cbc', Buffer.from(encryptionKey), iv);

let encrypted = cipher.update(text);

encrypted = Buffer.concat([encrypted, cipher.final()]);

return { iv: iv.toString('hex'), encryptedData: encrypted.toString('hex') };

}

function decrypt(text, iv) {

let iv_buf = Buffer.from(iv, 'hex');

let encryptedText = Buffer.from(text, 'hex');

const decipher = crypto.createDecipheriv('aes-256-cbc', Buffer.from(encryptionKey), iv_buf);

let decrypted = decipher.update(encryptedText);

decrypted = Buffer.concat([decrypted, decipher.final()]);

return decrypted.toString();

}

app.get('/encrypt/:data', (req, res) => {

const data = req.params.data;

const encryptedData = encrypt(data);

res.json(encryptedData);

});

app.get('/decrypt/:encryptedData/:iv', (req, res) => {

const encryptedData = req.params.encryptedData;

const iv = req.params.iv;

const decryptedData = decrypt(encryptedData, iv);

res.send(decryptedData);

});

// HTTPS configuration

const privateKey = fs.readFileSync('sslcert/key.pem', 'utf8');

const certificate = fs.readFileSync('sslcert/cert.pem', 'utf8');

const credentials = {key: privateKey, cert: certificate};

const httpsServer = https.createServer(credentials, app);

const PORT = process.env.PORT || 443;

httpsServer.listen(PORT, () => {

console.log("HTTPS server listening on port ${PORT}");

});

"""

**Explanation:**

* "crypto" module is used for encryption.

* AES-256-CBC algorithm is used.

* Encryption keys and IVs are generated randomly and stored securely.

* HTTPS is used to secure communication.

### Anti-Patterns

"""javascript

// Anti-pattern: Storing sensitive data in plaintext

// Anti-pattern: Using hardcoded encryption key

const encryptionKey = 'HardcodedKey'; // DO NOT DO THIS

"""

Storing sensitive data without encryption or hardcoding the encryption key presents a considerable vulnerability, as it makes the data accessible to unauthorized parties upon system compromise.

## 7. Cross-Site Scripting (XSS) Prevention

### Standard

Prevent XSS vulnerabilities by properly escaping output and using appropriate security headers.

* **Do This:** Use template engines with automatic escaping (e.g., Handlebars, Mustache, or JSX with React), sanitize user input before displaying it, set the "Content-Security-Policy" (CSP) header to restrict the sources from which resources can be loaded, and set the "X-XSS-Protection" header to enable the browser's built-in XSS filter..

* **Don't Do This:** Directly insert user input into HTML without escaping or sanitization.

### Why It Matters

XSS allows attackers to inject malicious scripts into web pages viewed by other users.

### Code Examples

**Node.js (Express.js) with escaping and CSP header:**

"""javascript

const express = require('express');

const hbs = require('hbs'); // Using Handlebars for templating with automatic escaping

const app = express();

app.set('view engine', 'hbs'); // set up handlebars view engine

app.use(express.urlencoded({ extended: true }));

app.use((req, res, next) => {

res.setHeader("Content-Security-Policy", "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'");

res.setHeader("X-XSS-Protection", "1; mode=block");

next();

});

app.get('/', (req, res) => {

res.render('index', { title: 'XSS Example', userInput: '' });

});

app.post('/submit', (req, res) => {

const userInput = req.body.userInput;

res.render('index', { title: 'XSS Example', userInput: userInput });

});

const PORT = process.env.PORT || 3000;

app.listen(PORT, () => {

console.log("Server is running on port ${PORT}");

});

"""

**index.hbs:**

"""html

Enter some text:

Submit

<p>You entered: {{userInput}}</p>

"""

**Explanation:**

* Handlebars template engine is used, which automatically escapes output to prevent XSS.

* CSP header is set to restrict the sources of content.

* "X-XSS-Protection" header is set to enable the browser's XSS filter in blocking mode.

### Anti-Patterns

"""javascript

// Anti-pattern: Directly inserting user input without escaping

app.get('/display', (req, res) => {

const userInput = req.query.input;

res.send("${userInput}"); // Vulnerable to XSS

});

"""

Directly embedding user input onto a web page without proper encoding creates a serious security risk. The lack of proper escaping allows malicious scripts contained within the user input to execute within the user's browser.

## 8. Cross-Site Request Forgery (CSRF) Prevention

### Standard

Protect against CSRF attacks by using anti-CSRF tokens.

* **Do This:** Generate and validate CSRF tokens for all state-changing requests (e.g., POST, PUT, DELETE). Use a library or framework that provides built-in CSRF protection (e.g., "csurf" middleware in Express.js). Implement "SameSite" cookie attribute: set the "SameSite" attribute for cookies to either "Strict" or "Lax".

* **Don't Do This:** Rely solely on "GET" requests for state-changing operations or disable CSRF protection.

### Why It Matters

CSRF allows attackers to perform actions on behalf of legitimate users without their knowledge.

### Code Examples

**Node.js (Express.js) with "csurf":**

"""javascript

const express = require('express');

const cookieParser = require('cookie-parser');

const csrf = require('csurf');

const app = express();

// Middleware

app.use(cookieParser());

const csrfProtection = csrf({ cookie: true });

app.use(express.urlencoded({ extended: false }));

app.get('/form', csrfProtection, (req, res) => {

// pass the csrfToken to the view

res.send("

Submit

");

});

app.post('/process', csrfProtection, (req, res) => {

res.send('Form is processed!');

});

const PORT = process.env.PORT || 3000;

app.listen(PORT, () => {

console.log("Server is running on port ${PORT}");

});

"""

**Explanation:**

* "csurf" middleware is used to generate and validate CSRF tokens.

* A hidden input field contains the CSRF token, which is submitted with the form.

* The server verifies the CSRF token before processing the request.

### Anti-Patterns

"""javascript

// Anti-pattern: Disabling CSRF protection

app.post('/transfer', (req, res) => {

// No CSRF protection

//...

});

"""

Code that lacks proper CSRF protection is vulnerable to malicious requests made on behalf of an authenticated user without their consent.

## 9. Denial of Service (DoS) Prevention

### Standard

Implement measures to mitigate DoS attacks.

* **Do This:** Limit request rates, implement timeouts, use rate limiting middleware (e.g., "express-rate-limit"), use a content delivery network (CDN), and protect against Slowloris attacks.

* **Don't Do This:** Allow unlimited requests or ignore potential DoS vulnerabilities.

### Why It Matters

DoS attacks can disrupt service availability and prevent legitimate users from accessing the application.

### Code Examples

**Node.js (Express.js) with "express-rate-limit":**

"""javascript

const express = require('express');

const rateLimit = require('express-rate-limit');

const app = express();

const limiter = rateLimit({

windowMs: 15 * 60 * 1000, // 15 minutes

max: 100, // Limit each IP to 100 requests per windowMs

message: 'Too many requests from this IP, please try again after 15 minutes',

standardHeaders: true, // Return rate limit info in the "RateLimit-*" headers

legacyHeaders: false, // Disable the "X-RateLimit-*" headers

});

app.use(limiter);

app.get('/', (req, res) => {

res.send('Welcome to rate limited app!');

});

const PORT = process.env.PORT || 3000;

app.listen(PORT, () => {

console.log("Server is running on port ${PORT}");

});

"""

**Explanation:**

* "express-rate-limit" middleware is used to limit the number of requests from each IP address.

* The rate limit is configured to allow 100 requests per 15 minutes.

### Anti-Patterns

"""javascript

// Anti-pattern: Allowing unlimited requests

app.get('/unprotected', (req, res) => {

// No rate limiting

res.send('Unprotected route');

});

"""

Allowing unlimited requests exposes the service to high traffic volume and increases the vulnerability to denial-of-service attacks.

## 10. Server-Side Request Forgery (SSRF) Prevention

### Standard

Prevent SSRF vulnerabilities by validating and sanitizing outbound requests.

* **Do This:** Whitelist allowed domains or IP addresses, validate URLs, disable URL redirection, and use secure protocols (HTTPS) for outbound requests. Avoid using user-supplied data directly in outbound requests.

* **Don't Do This:** Allow unrestricted outbound requests or trust user-supplied URLs.

### Why It Matters

SSRF allows attackers to make requests to internal resources or arbitrary external endpoints from the server, bypassing security controls.

### Code Examples

**Node.js with URL validation:**

"""javascript

const express = require('express');

const { URL } = require('url');

const https = require('https'); // Use HTTPS for outbound requests

const app = express();

app.use(express.json());

const allowedHosts = ['api.example.com', 'secure.example.org']; // Whitelist

app.post('/proxy', async (req, res) => {

try {

const targetUrl = req.body.url;

// URL validation

const url = new URL(targetUrl);

if (!allowedHosts.includes(url.hostname)) {

return res.status(400).send('Invalid target URL');

}

// Make outbound request (HTTPS)

https.get(targetUrl, (response) => {

let data = '';

response.on('data', (chunk) => {

data += chunk;

});

response.on('end', () => {

res.send(data);

});

}).on('error', (err) => {

console.error('Error making request:', err);

res.status(500).send('Error making outbound request');

});

} catch (error) {

console.error('Invalid URL:', error);

res.status(400).send('Invalid URL');

}

});

const PORT = process.env.PORT || 3000;

app.listen(PORT, () => {

console.log("Server is running on port ${PORT}");

});

"""

**Explanation:**

* The code validates the target URL against a whitelist of allowed hosts.

* It uses "https.get" to ensure secure communication.

### Anti-Patterns

"""javascript

// Anti-pattern: Using user-supplied URL directly

app.get('/proxy', (req, res) => {

const targetUrl = req.query.url; // User-supplied URL

//...

https.get(targetUrl, (response) => {

response.pipe(res); // Vulnerable to SSRF

});

"""

Directly using user provided URLs in outbound requests, without domain validation, makes the service vulnerable to Server Side Request Forgery threats. Limit outbound requests to validated URLs to prevent vulnerability.

By adhering to these security best practices, Monorepo developers can build more secure and reliable applications. These standards should be reviewed and updated regularly to stay ahead of emerging threats and vulnerabilities. Remember to implement security as a continuous process, not a one-time fix.

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 Monorepo

Cline

Overview

Key Concepts

Purpose of .clinerules

File Location

Rule Structure

1. Project Overview

2. Code Standards

3. Security Rules

Best Practices

Writing Effective Rules

Common Patterns

Integration with Development Workflow

Using with Version Control

Troubleshooting

Common Issues

Examples

Basic Project Setup

Advanced Configuration

Related Rules

Core Architecture Standards for Monorepo

Component Design Standards for Monorepo

State Management Standards for Monorepo

Performance Optimization Standards for Monorepo

Testing Methodologies Standards for Monorepo