Critical Validations Needed

[DomGarguilo]

1. Frame Duration Bounds
   - Reject animations with frameDuration < 16ms (too fast for human eye)
   - Reject animations with frameDuration > 300000ms (5+ minutes causes UX issues)
2. Memory Protection
   - Calculate total queue memory: sum(animations.length * frameCount * 768 bytes)
   - Reject if total exceeds maxQueueSizeBytes
   - Validate each frame is exactly 768 bytes
3. Loop Prevention
   - Limit repeatCount to prevent near-infinite loops
   - Limit total frames to prevent memory exhaustion
4. Injection Prevention
   - Sanitize animationID and frameID strings
   - Prevent path traversal attempts (../, ./, etc.)
   - Use allowlist patterns for IDs
5. Queue Bounds
   - Limit total animations in single metadata update
   - Prevent oversized individual animations

Implementation Notes

• Validate on metadata endpoint before storing/sending to ESP32
• Return clear error messages for validation failures
• Log validation failures for monitoring
• Consider rate limiting to prevent spam validation attempts

Acceptance Criteria

• All timing values validated within safe bounds
• Memory usage calculated and limited
• String inputs sanitized and length-limited
• Queue size limits enforced
• Clear error responses for validation failures
• Validation failures logged for monitoring

[DomGarguilo]

The ESP32 firmware has been updated to handle edge cases gracefully, but server-side validation is still recommended to prevent unnecessary data transmission:

• frameDuration ≤ 0: Firmware clamps to minimum 16ms, but wastes bandwidth
• repeatCount ≤ 0: Firmware skips animation entirely, but still processes metadata
• Empty frameOrder: Firmware skips animation, but metadata still transferred
• Negative values: Handled safely by firmware, but indicate data corruption

Recommended server minimums:
frameDuration: { min: 16 }, // Matches firmware minimum (60 FPS)
repeatCount: { min: 1 }, // Prevent skipped animations
frameOrder: { minLength: 1 } // Prevent empty animations