Hanami API Security
Hanami Security Posture
Hanami provides a secure foundation with several built-in protections, but developers often misconfigure these defaults. The framework ships with strong CSRF protection enabled by default for form submissions, and its routing system properly separates HTTP verbs, reducing method override attacks. Hanami's database layer uses prepared statements by default, mitigating SQL injection risks.
However, Hanami's minimalist philosophy means security features are opt-in rather than opt-out. Authentication and authorization aren't included in the core framework, leaving developers to implement these critical controls themselves. The framework also lacks built-in rate limiting, input sanitization, and security headers configuration—all essential for production APIs.
Most critically, Hanami's convention-over-configuration approach can create security blind spots. Developers unfamiliar with the framework might assume certain protections exist when they don't, or might not realize that security-related configurations are scattered across multiple files (actions, slices, and the application config).
Top 5 Security Pitfalls in Hanami
1. Missing Authentication in Actions
Hanami doesn't enforce authentication by default. A common mistake is creating API actions without any authentication checks, exposing sensitive data to unauthenticated users. Developers often forget to add authentication middleware or skip it during development, then deploy without re-enabling it.
2. Insecure Direct Object References (IDOR)
Hanami's slice architecture encourages clean separation of concerns, but developers frequently expose entity IDs directly in URLs without proper authorization checks. For example, /api/users/{id}/profile might return any user's profile if the action doesn't verify the requester has access to that specific user.
3. Mass Assignment Vulnerabilities
Hanami's repositories use strong parameters by default, but developers sometimes bypass these protections when creating custom actions or when using dynamic attribute assignment. An attacker could modify fields they shouldn't control, like user roles or permissions.
4. Inadequate Input Validation
While Hanami provides validation in its entities and forms, API actions often skip validation entirely or rely on client-side validation. This leaves endpoints vulnerable to malformed input, injection attacks, and data integrity issues.
5. Missing Security Headers and Rate Limiting
Hanami applications don't include security headers or rate limiting by default. Developers must explicitly configure CORS policies, Content Security Policy headers, and rate limiting middleware. Without these, APIs are vulnerable to cross-origin attacks, brute force attempts, and resource exhaustion.
Security Hardening Checklist
Authentication and Authorization
• Implement authentication middleware in your application config
• Use policies to enforce authorization checks in actions
• Never trust entity IDs from URL parameters—always verify access rights
Input Validation
• Validate all incoming parameters using Hanami's validation system
• Sanitize user input before database operations
• Use strong parameters to prevent mass assignment
Security Headers and CORS
• Configure CORS policies in your application config
• Add security headers (CSP, HSTS, X-Content-Type-Options) via middleware
• Restrict allowed origins and methods
Rate Limiting and Monitoring
• Implement rate limiting middleware for API endpoints
• Add request logging for security monitoring
• Monitor for unusual access patterns
Database Security
• Use parameterized queries (Hanami's default)
• Implement proper database user permissions
• Avoid raw SQL unless absolutely necessary
API Security Testing
• Test your Hanami API endpoints with automated security scanning
• Use middleBrick to scan your API surface and get a security risk score
• Integrate security testing into your CI/CD pipeline with the middleBrick GitHub Action