Secure Development Skill

Purpose

This skill ensures all code development follows security-by-design principles as defined in the Hack23 ISMS Secure Development Policy. It applies to all software development activities including web applications, APIs, infrastructure code, and scripts.

Rules

Input Validation

MUST:

Validate ALL user input at the point of entry (server-side validation is mandatory)
Use allowlist validation (define what IS allowed, not what ISN'T)
Validate data type, length, format, and range
Encode output before rendering to prevent XSS
Sanitize input before use in queries, commands, or file operations
Reject invalid input with clear error messages (without exposing system details)

MUST NOT:

Rely solely on client-side validation
Trust data from external sources (APIs, databases, files) without validation
Use blocklist validation as the primary defense
Echo raw user input back to the browser
Expose stack traces or system information in error messages

Authentication and Authorization

MUST:

Enforce authentication for all non-public resources
Implement multi-factor authentication (MFA) for administrative access
Use secure session management (HTTPOnly, Secure, SameSite cookies)
Enforce strong password policies (minimum 12 characters, complexity requirements)
Implement account lockout after failed login attempts (5 attempts)
Log all authentication events (success and failure)
Use the principle of least privilege for all access controls
Verify authorization at each access point, not just at entry

MUST NOT:

Store passwords in plaintext or reversible encryption
Use weak hashing algorithms (MD5, SHA-1) for passwords
Implement custom authentication schemes without security review
Share authentication credentials between users or systems
Grant broad access by default

Cryptography

MUST:

Use AES-256 for symmetric encryption
Use RSA-2048 or higher for asymmetric encryption
Use SHA-256 or higher for hashing
Enforce TLS 1.2 or higher for all network communications
Store cryptographic keys securely (use key management systems, not code)
Use cryptographically secure random number generators (not Math.random())
Rotate encryption keys according to policy

MUST NOT:

Hard-code encryption keys, passwords, or secrets in source code
Use deprecated algorithms (DES, 3DES, MD5, SHA-1, SSL, TLS 1.0/1.1)
Implement custom cryptographic algorithms
Store secrets in version control (use secret management tools)
Use weak or predictable initialization vectors (IVs)

Secure Error Handling

MUST:

Implement centralized error handling
Log all security-relevant errors with sufficient detail for investigation
Return generic error messages to users
Fail securely (deny access on error, don't fall back to insecure state)
Clean up resources in finally blocks or using equivalent patterns
Monitor and alert on unusual error patterns

MUST NOT:

Expose stack traces to users
Include sensitive data in error messages (passwords, keys, tokens, PII)
Log sensitive data (passwords, credit card numbers, SSNs)
Continue processing after critical security errors
Suppress security exceptions without logging

Secure Configuration

MUST:

Use environment variables or secret management for sensitive configuration
Implement secure defaults (disable debug mode, enable security headers)
Document all security-relevant configuration options
Review configuration changes for security implications
Use principle of least privilege for service accounts and API keys
Disable unnecessary features, services, and endpoints

MUST NOT:

Commit configuration files with secrets to version control
Use default credentials in production
Enable debug/verbose logging in production
Expose administrative interfaces to public networks
Use overly permissive CORS policies

Security Testing

MUST:

Perform static application security testing (SAST) on every commit
Perform dynamic application security testing (DAST) before production deployment
Include security test cases in test suites
Perform dependency vulnerability scanning
Test authentication and authorization controls
Test input validation for injection vulnerabilities
Document security test results

MUST NOT:

Deploy code without passing security scans
Ignore or suppress security findings without proper justification and approval
Test security controls in production environments
Use production data in testing environments

Dependency Management

MUST:

Use dependency scanning tools (e.g., Dependabot, Snyk)
Keep dependencies up to date with security patches
Review dependencies for known vulnerabilities before use
Use package lock files to ensure reproducible builds
Document approved dependencies and their versions
Remove unused dependencies

MUST NOT:

Use dependencies with known critical vulnerabilities
Use abandoned or unmaintained dependencies
Download dependencies from untrusted sources
Bypass dependency version constraints without security review

Code Review

MUST:

Require peer review for all code changes
Include security review in code review process
Use automated security scanning in PR pipelines
Document security decisions in PR comments
Verify security requirements are met before approval

MUST NOT:

Merge code without required approvals
Bypass security checks in CI/CD pipeline
Approve your own security-critical changes

Examples

Example 1: Secure Input Validation (JavaScript)

// GOOD: Allowlist validation with type checking function validateUsername(username) { // Define what IS allowed const usernameRegex = /^[a-zA-Z0-9_-]{3,20}$/;

// Validate type if (typeof username !== 'string') { throw new Error('Invalid input type'); }

// Validate format and length if (!usernameRegex.test(username)) { throw new Error('Username must be 3-20 characters and contain only letters, numbers, hyphens, and underscores'); }

return username; }

// BAD: No validation function validateUsernameBad(username) { return username; // Accepts anything! }

// BAD: Blocklist validation function validateUsernameBad2(username) { if (username.includes('<') || username.includes('>')) { throw new Error('Invalid characters'); } return username; // Still vulnerable to many attacks }

Example 2: Secure Password Hashing (Node.js)

const bcrypt = require('bcrypt');

// GOOD: Use strong hashing with salt async function hashPassword(password) { // MUST use at least 12 rounds (2^12 iterations) const saltRounds = 12; const hashedPassword = await bcrypt.hash(password, saltRounds); return hashedPassword; }

async function verifyPassword(password, hashedPassword) { return await bcrypt.compare(password, hashedPassword); }

// BAD: Using weak hashing const crypto = require('crypto'); function hashPasswordBad(password) { // NEVER use MD5 or SHA-1 for passwords! return crypto.createHash('md5').update(password).digest('hex'); }

// BAD: Storing plaintext function storePasswordBad(password) { return password; // NEVER store passwords in plaintext! }

Example 3: Secure Session Management (Express.js)

const session = require('express-session'); const RedisStore = require('connect-redis')(session);

// GOOD: Secure session configuration app.use(session({ store: new RedisStore({ client: redisClient }), secret: process.env.SESSION_SECRET, // From environment, not hardcoded name: 'sessionId', // Don't use default 'connect.sid' resave: false, saveUninitialized: false, cookie: { secure: true, // MUST use HTTPS httpOnly: true, // MUST prevent JavaScript access maxAge: 1800000, // 30 minutes sameSite: 'strict' // CSRF protection } }));

// BAD: Insecure session configuration app.use(session({ secret: 'mysecret123', // Hardcoded secret! cookie: { secure: false, // Allows HTTP httpOnly: false // Vulnerable to XSS } }));

Example 4: Preventing SQL Injection (Node.js)

const mysql = require('mysql2/promise');

// GOOD: Parameterized queries async function getUserByEmail(email) { const [rows] = await connection.execute( 'SELECT * FROM users WHERE email = ?', [email] ); return rows[0]; }

// BAD: String concatenation async function getUserByEmailBad(email) { // NEVER concatenate user input into SQL! const query = SELECT * FROM users WHERE email = '${email}'; const [rows] = await connection.execute(query); return rows[0]; }

Example 5: Secure Error Handling (Python)

import logging

GOOD: Generic error messages to users, detailed logging

def process_payment(user_id, amount): try: # Process payment logic charge_credit_card(user_id, amount) return {"success": True, "message": "Payment processed"} except CreditCardError as e: # Log detailed error securely logging.error(f"Payment failed for user {user_id}: {str(e)}", extra={"user_id": user_id, "amount": amount}) # Return generic message to user return {"success": False, "message": "Payment processing failed. Please try again."} except Exception as e: # Log unexpected errors logging.exception(f"Unexpected error processing payment for user {user_id}") # Return generic message return {"success": False, "message": "An error occurred. Please contact support."}

BAD: Exposing detailed errors

def process_payment_bad(user_id, amount): try: charge_credit_card(user_id, amount) return {"success": True} except Exception as e: # NEVER expose stack traces or system details to users! return {"success": False, "error": str(e), "trace": traceback.format_exc()}

Example 6: Secure Configuration (Environment Variables)

// GOOD: Use environment variables for secrets require('dotenv').config();

const config = { database: { host: process.env.DB_HOST, user: process.env.DB_USER, password: process.env.DB_PASSWORD, // Never hardcode! database: process.env.DB_NAME }, api: { key: process.env.API_KEY, secret: process.env.API_SECRET }, // Secure defaults security: { httpsOnly: true, hstsEnabled: true, debugMode: false } };

// Validate required environment variables const required = ['DB_HOST', 'DB_USER', 'DB_PASSWORD', 'API_KEY']; required.forEach(key => { if (!process.env[key]) { throw new Error(Missing required environment variable: ${key}); } });

// BAD: Hardcoded secrets const configBad = { database: { host: 'localhost', user: 'admin', password: 'P@ssw0rd123', // NEVER hardcode passwords! database: 'production' }, api: { key: 'sk_live_abcdef123456' // NEVER commit API keys! } };

Example 7: XSS Prevention (HTML Output Encoding)

// GOOD: Encode output before rendering function escapeHtml(unsafe) { return unsafe .replace(/&/g, "&") .replace(/</g, "<") .replace(/>/g, ">") .replace(/"/g, """) .replace(/'/g, "'"); }

function displayUserComment(comment) { const safeComment = escapeHtml(comment); document.getElementById('comment').innerHTML = safeComment; }

// Or use a trusted library const DOMPurify = require('dompurify'); function displayUserContent(content) { const clean = DOMPurify.sanitize(content); document.getElementById('content').innerHTML = clean; }

// BAD: Direct HTML insertion function displayUserCommentBad(comment) { // NEVER insert unsanitized user input into HTML! document.getElementById('comment').innerHTML = comment; }

Related ISMS Policies

This skill implements requirements from:

Secure Development Policy - Primary policy for secure coding practices
Access Control Policy - Authentication and authorization requirements
Cryptographic Controls Policy - Encryption and hashing requirements
Information Security Policy - Overall security framework
Data Classification Policy - Data handling requirements

secure-development

Safety Notice

Copy this and send it to your AI assistant to learn

GOOD: Generic error messages to users, detailed logging

BAD: Exposing detailed errors

Source Transparency

Related Skills

github-actions-cicd

secure-code-review

agentic-workflow-development