Security Policy

At ToolBelt (operated by Sarvasv Technologies Private Limited), maintaining the confidentiality, integrity, and availability of our users' operational and personal data is fundamental to our engineering standards. We employ a rigorous, multi-layered defense-in-depth posture spanning physical network boundaries, infrastructure isolation, application runtime fortifications, and strict access controls.

1. Perimeter and Network Architecture

Our production environments are architected around strict network isolation to minimize the attack surface:

• Network Isolation via Private VPN: All production compute instances are deployed within dedicated, private virtual environments isolated behind an encrypted, authenticated Virtual Private Network (VPN).
• Minimal Ingress Attack Surface: External perimeter firewalls permit ingress exclusively on standard web ports: HTTP (port 80) and HTTPS (port 443). Port 80 unconditionally enforces an immediate 301 permanent redirect to HTTPS.
• Closed Administrative Perimeter: All administrative endpoints, system shells (SSH), relational databases, caches, and internal monitoring services are completely closed to the public internet. Access requires multi-factor authentication across private encrypted VPN tunnels.

2. Transport Security and HTTP Defensive Headers

All data in transit across public networks is protected using hardened transport-layer encryption and modern defensive headers:

• Enforced TLS Encryption: We enforce TLS 1.3 and TLS 1.2 with forward secrecy cipher suites. Plaintext HTTP traffic is rejected.
• HTTP Strict Transport Security (HSTS): The Strict-Transport-Security directive is enforced with extended durations, including subdomains and preload declarations, preventing protocol downgrade and cookie interception.
• Clickjacking Protection: Framing defenses are enforced via X-Frame-Options: DENY and frame-ancestors directives, blocking any unauthorized iframe embedding.
• MIME Confusion Defense: X-Content-Type-Options: nosniff is strictly set on all responses to prevent MIME-type spoofing and execution.
• Cross-Domain Isolation: Responses include X-Permitted-Cross-Domain-Policies: none and restrictive Referrer-Policy: strict-origin-when-cross-origin to limit cross-origin data leakage.
• Content Security Policy (CSP): Layered resource policies restrict the origin of executable scripts, stylesheets, and embedded assets.

3. Session Security and State Management

Session tracking and authentication states are engineered with cryptographic protections to defend against interception, replay, and session fixation:

• Hardened Cookie Attributes: All authentication and session cookies are delivered strictly with Secure, HttpOnly, and SameSite flags, preventing access via client-side scripts and defending against cross-site request attacks.
• Cryptographically Encrypted Session Stores: Sessions are protected using cryptographic signatures and authenticated encryption algorithms. Key derivation configurations undergo scheduled rotation.
• Session Fixation Elimination: Application session identifiers are systematically regenerated upon user login, logout, and any privilege transition, invalidating previously issued identifiers.
• Replay Attack Defenses: Session validity is coupled to server-side nonces, device context, and strict inactivity and absolute expiration ceilings.

4. Cross-Site Request Forgery (CSRF) Prevention

We employ universal anti-forgery protections across all state-changing interactions:

• Cryptographically Unpredictable Tokens: Every mutating HTTP request (POST, PUT, PATCH, DELETE) requires a unique, cryptographically generated authenticity token bound to the active user session.
• Strict Rejection: Any request submitted without a valid matching authenticity token is immediately rejected and terminated at the controller layer before business logic executes.

5. Injection Attack Immunities

Input handling is governed by strict positive schema validation, rejecting unvalidated data before it reaches internal subsystems:

• SQL Injection Immunity: All database queries are constructed exclusively through parameterized query interfaces and high-level object abstraction layers. Dynamic string interpolation in database operations is architecturally barred.
• Cross-Site Scripting (XSS) Prevention: All dynamic view rendering automatically enforces context-aware HTML entity encoding by default. Unsanitized raw user input is never reflected into document markup.
• Command Injection Immunity: Operating system shell execution via user-controlled input is prohibited. System operations utilize safe, direct application program interfaces without shell interpolation.
• Header and Response Splitting Defense: All HTTP response headers undergo automated carriage-return and line-feed (CRLF) stripping to prevent header injection or proxy cache poisoning.
• Unsafe Query Defense: Deep parameter parsing is fortified with type verification and structured schema constraints to prevent parameter tampering or unexpected query construction.

6. Redirection and File Handling Security

File processing and URL handling follow strict boundary isolation principles:

• Open Redirection Prevention: Redirection targets are validated against an explicit whitelist of internal application endpoints. Arbitrary user-supplied target URLs are rejected.
• File Upload Isolation: Uploaded business attachments are stored in dedicated non-executable storage locations segregated from web execution roots.
• Content and MIME Verification: All incoming files undergo deep inspection of header magic bytes and MIME signatures. Executable binaries, scripts, or disguised payloads are immediately rejected.
• Path Traversal Immunity: Direct filesystem path references are disallowed. File retrieval operates entirely through opaque database record keys, preventing directory traversal attacks.

7. Identity, Access, and User Management

User identity and privilege management are protected by continuous verification controls:

• Brute-Force and Bot Throttling: Authentication endpoints enforce progressive delays, aggressive rate limiting, and anomalous request throttling.
• Password Reset Safeguards: Password recovery mechanisms utilize cryptographically random, single-use tokens governed by short expiration windows. Reset tokens are instantly invalidated upon use or password change.
• Log Sanitization: Automated parameter filtering permanently masks passwords, authentication tokens, API keys, and sensitive financial/PII data before operational logs are written.
• Boundary Anchor Validation: Regular expression validators strictly enforce string-beginning and string-ending anchors to prevent multiline validation bypasses.
• Mass Assignment and Privilege Escalation Prevention: Request parameters undergo strict attribute whitelisting at the controller boundary. Unauthorized privilege escalation or mass attribute modifications are structurally impossible.
• Constant-Time Cryptographic Verification: Sensitive token and credential comparisons utilize constant-time algorithmic operations to prevent side-channel timing attacks.

8. Secrets Management and Continuous Vulnerability Auditing

Operational secrets and third-party dependencies are continuously monitored and audited:

• Encrypted Secrets Storage: Application credentials, encryption keys, and third-party API tokens are maintained in encrypted vaults; plaintext secrets are never committed to version control.
• Automated CVE Scanning: Continuous automated dependency scanners inspect all software packages against known Common Vulnerabilities and Exposures (CVE) databases.
• Patch Management: Critical security advisories and kernel/runtime updates are deployed promptly according to our vulnerability remediation policy.

9. Third-Party Payments and Privacy Alignment

Payment processing is offloaded to PCI-DSS compliant payment gateways (Razorpay), ensuring that sensitive payment card data is never stored on our servers. For detailed disclosures on user data processing, Google OAuth authentication boundaries, data retention, and account deletion rights, please consult our Privacy Policy.

10. Vulnerability Disclosure and Security Inquiries

We welcome collaboration with responsible security researchers. If you identify a potential security issue in ToolBelt, we request that you report it to us immediately and refrain from publishing or disclosing findings until we have had an opportunity to investigate and remediate the issue.

To report a vulnerability, please submit full technical details through our secure security intake form or contact our security team at: