FieldOps Hub handles sensitive business data — customer personally identifiable information, service location details, financial records, and payment history. We take security seriously and appreciate responsible disclosure from the security community.

Only the latest release on the production branch receives security patches. We do not backport fixes to older releases.

Please do not open a public GitHub issue for security vulnerabilities.

Report vulnerabilities privately using one of the following methods:

• GitHub Private Advisory — Submit via GitHub Security Advisories (preferred)
• Email — Send details to the repository owner through GitHub's contact information

To help us triage quickly, please provide as much of the following as possible:

• A clear description of the vulnerability and its potential impact
• The component, route, or feature affected
• Step-by-step reproduction instructions
• Proof-of-concept code or a screenshot (if applicable)
• Your suggested severity (Critical / High / Medium / Low)
• Whether you have already disclosed this to any third party

We will keep you updated throughout the process and credit you in the release notes unless you prefer to remain anonymous.

The following are valid targets for security research:

• Authentication — login, registration, password reset, 2FA (TOTP), session management
• Authorization — role-based access control, permission enforcement, cross-tenant data access
• API endpoints — all routes in routes/web.php, routes/auth.php, and routes/settings.php
• File uploads — attachment handling, MIME type validation, path traversal
• Data exposure — unintended PII or financial data leakage in Inertia shared props or API responses
• Injection — SQL injection, XSS, command injection, mass assignment
• Multi-tenancy — ability to access or modify another organization's data

The following are explicitly excluded:

• Denial of service (DoS/DDoS) attacks
• Spam, phishing, or social engineering attacks against users or staff
• Vulnerabilities in third-party dependencies that are already publicly disclosed (report these to the upstream project)
• Issues requiring physical access to infrastructure
• Missing HTTP security headers on non-sensitive static assets
• Rate limiting on endpoints that do not process sensitive data
• Self-XSS that cannot be used to attack other users
• Theoretical vulnerabilities without a working proof-of-concept
• The .env.example file or other non-production configuration examples

For context when evaluating the attack surface, FieldOps Hub includes the following security controls:

We follow a coordinated disclosure model:

1. Reporter submits a private report.
2. We triage, reproduce, and assess severity.
3. We develop and test a fix.
4. We deploy the fix to production.
5. We notify the reporter and agree on a disclosure date (typically 7 days after the fix ships).
6. We publish a security advisory crediting the reporter (unless anonymity is requested).

We ask that you:

• Give us a reasonable amount of time to fix the issue before any public disclosure.
• Avoid accessing, modifying, or deleting data that does not belong to a test account you control.
• Not perform testing that degrades service availability for other users.

We gratefully acknowledge security researchers who have helped improve FieldOps Hub. Researchers who responsibly disclose valid vulnerabilities will be listed here (with permission).

No entries yet.

Security research conducted in good faith, following this policy, will not result in legal action from us. We consider this a safe-harbor for researchers acting within the scope defined above.