We release patches for security vulnerabilities. The following versions are currently being supported with security updates:
| Version | Supported |
|---|---|
| 1.0.x | ✅ |
| < 1.0 | ❌ |
The SafeCap team takes security bugs seriously. We appreciate your efforts to responsibly disclose your findings and will make every effort to acknowledge your contributions.
Please do not report security vulnerabilities through public GitHub issues.
Instead, please report them via email to the project maintainers. You should receive a response within 48 hours. If for some reason you do not, please follow up via email to ensure we received your original message.
To help us better understand the nature and scope of the possible issue, please include as much of the following information as possible:
- Type of issue (e.g., buffer overflow, SQL injection, cross-site scripting, etc.)
- Full paths of source file(s) related to the manifestation of the issue
- The location of the affected source code (tag/branch/commit or direct URL)
- Any special configuration required to reproduce the issue
- Step-by-step instructions to reproduce the issue
- Proof-of-concept or exploit code (if possible)
- Impact of the issue, including how an attacker might exploit it
This information will help us triage your report more quickly.
When using SafeCap, we recommend following these security best practices:
- Always use strong passwords (minimum 12 characters recommended)
- Rotate JWT secrets regularly in production
- Keep JWT expiration times short for sensitive operations
- Implement proper role-based access control
- Never commit sensitive data (passwords, API keys, secrets) to version control
- Use environment variables for all sensitive configuration
- Ensure
.envfiles are in.gitignore - Use different credentials for development, staging, and production
- Use prepared statements (JPA handles this automatically)
- Follow principle of least privilege for database users
- Regularly backup your database
- Encrypt sensitive data at rest
- Always use HTTPS in production
- Configure CORS properly for your domain
- Implement rate limiting to prevent abuse
- Use firewall rules to restrict database access
- Regularly update dependencies to patch vulnerabilities
- Use Maven's dependency-check plugin (already configured)
- Monitor security advisories for dependencies
- Remove unused dependencies
- Run application with non-root user
- Keep JVM and OS updated
- Use container scanning tools for Docker images
- Implement proper logging and monitoring
SafeCap includes several built-in security features:
- JWT-based stateless authentication
- BCrypt password hashing with salt
- Token expiration and validation
- Bean Validation (JSR 380) for all inputs
- XSS protection
- SQL injection prevention via JPA
- CORS configuration
- Security headers configured via Spring Security
- Automatic timestamp tracking for all entities
- Request/response logging (configurable)
Security updates will be released as patch versions (e.g., 1.0.1, 1.0.2) and will be documented in the CHANGELOG.md.
When a security vulnerability is fixed:
- A new patch version will be released
- The vulnerability will be documented in CHANGELOG.md
- A security advisory will be published on GitHub
- Affected versions will be clearly identified
We encourage security testing of SafeCap, but please follow these guidelines:
- Security research on your own installation
- Reporting vulnerabilities through proper channels
- Testing with explicit permission
- Testing on production systems without permission
- Denial of service testing
- Accessing or modifying data you don't own
- Social engineering attacks
We recognize and thank security researchers who help improve SafeCap's security:
- Thank you to all security researchers who help keep SafeCap secure!
When a security vulnerability is reported:
- We will acknowledge receipt within 48 hours
- We will provide an initial assessment within 5 business days
- We will work on a fix and keep you informed of progress
- We will release a patched version as soon as possible
- We will publicly disclose the vulnerability after a patch is available
We ask that you:
- Give us reasonable time to fix the issue before public disclosure
- Make a good faith effort to avoid privacy violations and service disruption
- Do not exploit the vulnerability beyond what is necessary to demonstrate it
If you have questions about this security policy, please open an issue in the GitHub repository (for general questions only, not for reporting vulnerabilities).
Last Updated: December 2025