Skip to main content

Security Policy for Cache Module

This document outlines security procedures, threat models, and policies for the Cache module.

Security Overview​

The Cache module provides data caching functionality with multiple backend options including in-memory, file-based, and Redis backends. Caching systems are critical security components as they store potentially sensitive data and can be targets for various attacks including cache poisoning, data exposure, and denial of service attacks.

Security Principles​

  • Defense in Depth: Multiple layers of protection against cache-related attacks
  • Least Privilege: Minimal access permissions for cache operations
  • Data Minimization: Cache only necessary data with appropriate TTLs
  • Secure by Default: Conservative default configurations that prioritize security

Threat Model​

Assets Protected​

  • Cached application data
  • User session information
  • API response data
  • Computed values and aggregations
  • System configuration data

Threat Actors​

  1. External Attackers: Attempting to poison cache or extract sensitive data
  2. Malicious Insiders: Abusing cache access for unauthorized data retrieval
  3. Compromised Applications: Using cache as attack vector for lateral movement
  4. Automated Bots: Attempting denial of service through cache flooding

Attack Vectors​

Cache Poisoning​

Threat Level: High

Description: Attackers inject malicious data into the cache, which is then served to legitimate users.

Attack Scenarios:

  • Exploiting race conditions in cache update logic
  • HTTP response splitting attacks affecting cached responses
  • Manipulating cache keys to overwrite legitimate entries
  • Exploiting deserialization vulnerabilities in cached objects

Mitigations:

  • Validate all data before caching
  • Use cryptographic signatures for critical cached data
  • Implement strict cache key namespacing
  • Use safe serialization methods (avoid pickle for untrusted data)

Data Exposure​

Threat Level: High

Description: Sensitive cached data is exposed to unauthorized parties.

Attack Scenarios:

  • Unauthorized access to cache storage (file system, Redis)
  • Memory dumps revealing cached secrets
  • Cache key enumeration attacks
  • Side-channel attacks through timing analysis

Mitigations:

  • Encrypt sensitive cached data at rest
  • Use secure cache backends with authentication
  • Implement proper access controls
  • Use opaque, unpredictable cache keys for sensitive data

Cache Invalidation Attacks​

Threat Level: Medium

Description: Attackers manipulate cache invalidation to cause stale data serving or denial of service.

Attack Scenarios:

  • Forcing premature cache invalidation to increase backend load
  • Preventing cache invalidation to serve stale/malicious data
  • Cache stampede attacks during invalidation events
  • Time-based attacks exploiting TTL boundaries

Mitigations:

  • Implement cache locks and mutex for critical updates
  • Use probabilistic early expiration to prevent stampedes
  • Authenticate cache invalidation requests
  • Monitor invalidation patterns for anomalies

Memory Exhaustion​

Threat Level: High

Description: Attackers cause denial of service by exhausting cache memory.

Attack Scenarios:

  • Flooding cache with unique keys
  • Storing oversized values
  • Exploiting unbounded cache growth
  • Triggering expensive cache computations

Mitigations:

  • Enforce strict cache size limits
  • Implement maximum entry size limits
  • Use LRU or similar eviction policies
  • Rate limit cache write operations
  • Monitor memory usage with alerts

Security Controls​

Input Validation​

# Always validate data before caching
from codomyrmex.cache import CacheManager

def safe_cache_set(key: str, value: any, ttl: int = 300):
    # Validate key format
    if not is_valid_cache_key(key):
        raise ValueError("Invalid cache key format")

    # Validate value size
    if get_serialized_size(value) > MAX_CACHE_VALUE_SIZE:
        raise ValueError("Cache value exceeds maximum size")

    # Validate TTL
    if ttl < MIN_TTL or ttl > MAX_TTL:
        raise ValueError("Invalid TTL value")

    cache.set(key, value, ttl=ttl)

Access Control​

  • Backend Authentication: Always enable authentication for Redis and external cache backends
  • Namespace Isolation: Use namespaces to isolate cache data between components
  • Permission Validation: Verify caller permissions before cache operations

Data Protection​

  • Encryption: Encrypt sensitive data before caching
  • Key Hashing: Hash cache keys derived from user data
  • Secure Serialization: Use JSON or safe serialization; avoid pickle for untrusted data

Monitoring and Logging​

  • Log cache access patterns (without logging sensitive values)
  • Monitor for unusual cache hit/miss ratios
  • Alert on memory threshold violations
  • Track cache key cardinality

Secure Usage Guidelines​

Do's​

  1. Use Namespaced Caches

    from codomyrmex.cache import get_cache

    # Isolate user data from system data
    user_cache = get_cache("user_data", backend="in_memory")
    system_cache = get_cache("system_config", backend="in_memory")

  2. Set Appropriate TTLs

    # Shorter TTLs for sensitive data
    cache.set("auth_token", token, ttl=300)  # 5 minutes

    # Longer TTLs for static data
    cache.set("static_config", config, ttl=3600)  # 1 hour

  3. Implement Size Limits

    # Configure maximum cache size
    cache = CacheManager(max_size=1000, max_memory_mb=256)

  4. Validate Before Caching

    # Validate data structure before caching
    if validate_schema(data, expected_schema):
        cache.set(key, data)

  5. Use Secure Backends in Production

    # Redis with TLS and authentication
    redis_cache = get_cache(
        "production",
        backend="redis",
        host="redis.internal",
        port=6379,
        password=os.environ.get("REDIS_PASSWORD"),
        ssl=True
    )

Don'ts​

  1. Never Cache Sensitive Credentials

    # BAD: Caching plaintext passwords
    cache.set(f"user:{user_id}:password", password)

    # GOOD: Don't cache passwords at all

  2. Avoid User-Controlled Cache Keys

    # BAD: Direct user input in cache key
    cache.get(f"data:{user_input}")

    # GOOD: Hash or validate user input
    safe_key = hashlib.sha256(user_input.encode()).hexdigest()
    cache.get(f"data:{safe_key}")

  3. Don't Disable Size Limits

    # BAD: Unbounded cache
    cache = CacheManager(max_size=None)

    # GOOD: Always set limits
    cache = CacheManager(max_size=10000)

  4. Avoid Pickle for Untrusted Data

    # BAD: Using pickle for external data
    import pickle
    cache.set("external_data", pickle.dumps(untrusted_data))

    # GOOD: Use safe serialization
    import json
    cache.set("external_data", json.dumps(trusted_data))

Known Vulnerabilities​

CVE Registry​

No known CVEs at this time. This section will be updated as vulnerabilities are discovered and patched.

Security Advisories​

DateSeverityDescriptionResolution
--No current advisories-

Deprecated Features​

  • Pickle Serialization: Deprecated for untrusted data sources. Use JSON serialization instead.

Security Testing​

Automated Security Tests​

# Example security test cases
import pytest
from codomyrmex.cache import get_cache

class TestCacheSecurity:

    def test_cache_key_injection(self):
        """Verify cache keys are properly sanitized."""
        cache = get_cache("test")
        malicious_key = "../../../etc/passwd"
        with pytest.raises(ValueError):
            cache.set(malicious_key, "data")

    def test_cache_size_limit(self):
        """Verify cache respects size limits."""
        cache = get_cache("test", max_size=10)
        for i in range(20):
            cache.set(f"key_{i}", f"value_{i}")
        assert cache.size() <= 10

    def test_cache_value_size_limit(self):
        """Verify large values are rejected."""
        cache = get_cache("test", max_value_size=1024)
        large_value = "x" * 10000
        with pytest.raises(ValueError):
            cache.set("key", large_value)

    def test_namespace_isolation(self):
        """Verify namespaces are properly isolated."""
        cache_a = get_cache("namespace_a")
        cache_b = get_cache("namespace_b")
        cache_a.set("key", "value_a")
        assert cache_b.get("key") is None

Penetration Testing Checklist​

  • Test cache key injection attacks
  • Test cache poisoning scenarios
  • Verify memory exhaustion protection
  • Test cache timing attacks
  • Verify backend authentication
  • Test cache invalidation security
  • Verify sensitive data is not logged

Security Scanning​

Run security scans with:

# Static analysis
bandit -r src/codomyrmex/cache/

# Dependency vulnerabilities
safety check

# Type checking for security issues
ty check src/codomyrmex/cache/

Incident Response​

Reporting a Vulnerability​

If you discover a security vulnerability within this module, please report it to us as soon as possible. We take all security reports seriously.

DO NOT report security vulnerabilities through public GitHub issues.

Instead, please email security@codomyrmex.dev with the subject line: "SECURITY Vulnerability Report: Cache Module - [Brief Description]".

Please include the following information in your report:

  • A description of the vulnerability and its potential impact.
  • Steps to reproduce the vulnerability, including any specific configurations or conditions required.
  • Any proof-of-concept code or examples.
  • The version(s) of the module affected.
  • Your name and contact information (optional).

We aim to acknowledge receipt of your vulnerability report within 2-3 business days and will work with you to understand and remediate the issue.

Response Procedures​

Cache Poisoning Incident​

  1. Immediate: Flush affected cache namespace
  2. Short-term: Enable enhanced logging and monitoring
  3. Investigation: Analyze access logs to identify attack vector
  4. Remediation: Patch vulnerability and redeploy
  5. Post-incident: Review and update security controls

Data Exposure Incident​

  1. Immediate: Rotate any exposed credentials/tokens
  2. Short-term: Disable affected cache backend
  3. Investigation: Determine scope of exposure
  4. Notification: Alert affected users if required
  5. Remediation: Implement additional encryption/access controls

Denial of Service Incident​

  1. Immediate: Enable rate limiting on cache operations
  2. Short-term: Increase cache capacity or clear non-critical entries
  3. Investigation: Identify attack source and pattern
  4. Remediation: Block malicious actors, tune limits
  5. Post-incident: Review capacity planning

Security Updates​

Security patches and updates for this module will be documented in the module changelog and released as part of regular version updates. Critical vulnerabilities may warrant out-of-band releases.

Scope​

This security policy applies only to the Cache module within the Codomyrmex project. For project-wide security concerns, please refer to the main project's security policy or contact the core project maintainers.

Thank you for helping keep Codomyrmex and the Cache module secure.