vibe-security

Secure Coding Guide for Web Applications

Overview

This guide provides comprehensive secure coding practices for web applications. As an AI assistant, your role is to approach code from a bug hunter's perspective and make applications as secure as possible without breaking functionality.

SecurityPrinciples {
  Constraints {
    Defense in depth: Never rely on a single security control.
    Fail securely: When something fails, fail closed (deny access).
    Least privilege: Grant minimum permissions necessary.
    Input validation: Never trust user input, validate everything server-side.
    Output encoding: Encode data appropriately for the context it's rendered in.
  }
}

---

Access Control Issues

Access control vulnerabilities occur when users can access resources or perform actions beyond their intended permissions.

Core Requirements

AccessControl {
  User-Level Authorization
    require Each user must only access/modify their own data.
    require No user should access data from other users or organizations.
    require Always verify ownership at data layer, not just route level.

  Use UUIDs Instead of Sequential IDs
    require Use UUIDv4 or similar non-guessable identifiers.
    warn "Sequential IDs allowed only if explicitly requested by user"

  Account Lifecycle Handling
    require When user removed from organization: immediately revoke all access tokens and sessions.
    require When account deleted/deactivated: invalidate all active sessions and API keys.
    require Implement token revocation lists or short-lived tokens with refresh mechanisms.

  Constraints {
    Verify user owns the resource on every request (don't trust client-side data).
    Check organization membership for multi-tenant apps.
    Validate role permissions for role-based actions.
    Re-validate permissions after any privilege change.
    Check parent resource ownership (e.g., if accessing comment, verify user owns parent post).
  }
}

Common Pitfalls to Avoid

• IDOR (Insecure Direct Object Reference): Always verify the requesting user has permission to access the requested resource ID
• Privilege Escalation: Validate role changes server-side; never trust role info from client
• Horizontal Access: User A accessing User B's resources with the same privilege level
• Vertical Access: Regular user accessing admin functionality
• Mass Assignment: Filter which fields users can update; don't blindly accept all request body fields

Implementation Pattern

# Pseudocode for secure resource access
function getResource(resourceId, currentUser):
    resource = database.find(resourceId)

    if resource is null:
        return 404  # Don't reveal if resource exists

    if resource.ownerId != currentUser.id:
        if not currentUser.hasOrgAccess(resource.orgId):
            return 404  # Return 404, not 403, to prevent enumeration

    return resource

---

Client-Side Bugs

Cross-Site Scripting (XSS)

Every input controllable by the user—whether directly or indirectly—must be sanitized against XSS.

Input Sources to Protect

Direct Inputs:

• Form fields (email, name, bio, comments, etc.)
• Search queries
• File names during upload
• Rich text editors / WYSIWYG content

Indirect Inputs:

• URL parameters and query strings
• URL fragments (hash values)
• HTTP headers used in the application (Referer, User-Agent if displayed)
• Data from third-party APIs displayed to users
• WebSocket messages
• postMessage data from iframes
• LocalStorage/SessionStorage values if rendered

Often Overlooked:

• Error messages that reflect user input
• PDF/document generators that accept HTML
• Email templates with user data
• Log viewers in admin panels
• JSON responses rendered as HTML
• SVG file uploads (can contain JavaScript)
• Markdown rendering (if allowing HTML)

Protection Strategies

XSSProtection {
  Output Encoding (Context-Specific)
    require HTML context: HTML entity encode (`<` to `&lt;`).
    require JavaScript context: JavaScript escape.
    require URL context: URL encode.
    require CSS context: CSS escape.
    require Use framework's built-in escaping (React's JSX, Vue's {{ }}, etc.).

  Input Sanitization
    require Use established libraries (DOMPurify for HTML).
    require Whitelist allowed tags/attributes for rich text.
    require Strip or encode dangerous patterns.

  CSP {
    template: """
      Content-Security-Policy:
        default-src 'self';
        script-src 'self';
        style-src 'self' 'unsafe-inline';
        img-src 'self' data: https:;
        font-src 'self';
        connect-src 'self' https://api.yourdomain.com;
        frame-ancestors 'none';
        base-uri 'self';
        form-action 'self';
    """

    Constraints {
      Avoid `'unsafe-inline'` and `'unsafe-eval'` for scripts.
      Use nonces or hashes for inline scripts when necessary.
      Report violations: `report-uri /csp-report`.
    }
  }

  AdditionalHeaders {
    require X-Content-Type-Options: nosniff.
    require X-Frame-Options: DENY (or use CSP frame-ancestors).
  }
}

---

Cross-Site Request Forgery (CSRF)

Every state-changing endpoint must be protected against CSRF attacks.

Endpoints Requiring CSRF Protection

Authenticated Actions:

• All POST, PUT, PATCH, DELETE requests
• Any GET request that changes state (fix these to use proper HTTP methods)
• File uploads
• Settings changes
• Payment/transaction endpoints

Pre-Authentication Actions:

• Login endpoints (prevent login CSRF)
• Signup endpoints
• Password reset request endpoints
• Password change endpoints
• Email/phone verification endpoints
• OAuth callback endpoints

Protection Mechanisms

CSRFProtection {
  TokenRequirements {
    require Token is cryptographically random (use secure random generator).
    require Token is tied to user session.
    require Token is validated server-side on all state-changing requests.
    require Missing token = rejected request.
    require Token regenerated on authentication state change.
  }

  CookieSettings {
    require SameSite cookie attribute is set.
    require Secure flag on session cookies.
    require HttpOnly flag on session cookies.

    template: """
      Set-Cookie: session=abc123; SameSite=Strict; Secure; HttpOnly
    """

    SameSiteOptions {
      Strict: Cookie never sent cross-site (best security).
      Lax: Cookie sent on top-level navigations (good balance).
      warn "Always combine with CSRF tokens for defense in depth"
    }
  }

  DoubleSubmitPattern {
    Send CSRF token in both cookie and request body/header.
    Server validates they match.
  }
}

Edge Cases and Common Mistakes

• Token presence check: CSRF validation must NOT depend on whether the token is present, always require it
• Token per form: Consider unique tokens per form for sensitive operations
• JSON APIs: Don't assume JSON content-type prevents CSRF; validate Origin/Referer headers AND use tokens
• CORS misconfiguration: Overly permissive CORS can bypass SameSite cookies
• Subdomains: CSRF tokens should be scoped because subdomain takeover can lead to CSRF
• Flash/PDF uploads: Legacy browser plugins could bypass SameSite
• GET requests with side effects: Never perform state changes on GET
• Token leakage: Don't include CSRF tokens in URLs
• Token in URL vs Header: Prefer custom headers (X-CSRF-Token) over URL parameters

---

Secret Keys and Sensitive Data Exposure

No secrets or sensitive information should be accessible to client-side code.

SecretProtection {
  NeverExposeClientSide {
    Constraints {
      Third-party API keys (Stripe, AWS, etc.) must not be in client code.
      Database connection strings must not be in client code.
      JWT signing secrets must not be in client code.
      Encryption keys must not be in client code.
      OAuth client secrets must not be in client code.
      Internal service URLs/credentials must not be in client code.

      Full credit card numbers must not be in client code.
      Social Security Numbers must not be in client code.
      Passwords (even hashed) must not be in client code.
      Security questions/answers must not be in client code.
      Full phone numbers (mask them: ***-***-1234) must not be in client code.
      Sensitive PII that isn't needed for display must not be in client code.

      Internal IP addresses must not be in client code.
      Database schemas must not be in client code.
      Debug information must not be in client code.
      Stack traces in production must not be in client code.
      Server software versions must not be in client code.
    }
  }

  CheckTheseLocations {
    warn "JavaScript bundles (including source maps)"
    warn "HTML comments"
    warn "Hidden form fields"
    warn "Data attributes"
    warn "LocalStorage/SessionStorage"
    warn "Initial state/hydration data in SSR apps"
    warn "Environment variables exposed via build tools (NEXT_PUBLIC_*, REACT_APP_*)"
  }

  BestPractices {
    require Store secrets in `.env` files.
    require Make API calls requiring secrets from backend only.
  }
}

---

Open Redirect

Any endpoint accepting a URL for redirection must be protected against open redirect attacks.

Protection Strategies

OpenRedirectProtection {
  Allowlist Validation (preferred)
    require Only allow requests to pre-approved domains.
    require Maintain a strict allowlist for integrations.

  Relative URLs Only
    require Only accept paths (e.g., `/dashboard`) not full URLs.
    require Validate the path starts with `/` and doesn't contain `//`.

  Indirect References
    require Use a mapping instead of raw URLs: `?redirect=dashboard` maps to `/dashboard`.

  isValidRedirect(url) {
    allowed_domains = ['yourdomain.com', 'app.yourdomain.com']
    parsed = parseUrl(url

---

*Content truncated.*