Security

DOCKEX LLC builds and operates software for commercial fleet operators: businesses that depend on accurate, timely, and confidential handling of their registration, compliance, and financial data. We treat security not as a compliance checkbox but as a fundamental product requirement.

Our platform is built on AWS infrastructure, uses industry-standard encryption protocols, delegates all payment processing to a PCI DSS Level 1 certified provider, and enforces fine-grained access controls across every user role. We invest continuously in identifying and remediating vulnerabilities before they can be exploited.

Questions about our security practices can be directed to contact@dockex.io.

DOCKEX runs entirely on Amazon Web Services (AWS), one of the world's most audited and certified cloud infrastructure providers. AWS maintains certifications including SOC 1/2/3, ISO 27001, PCI DSS, FedRAMP, and others. Inheriting these controls allows DOCKEX to build on a security-hardened foundation.

TLS and HTTPS Enforcement

All network communication between clients and DOCKEX services is encrypted using TLS 1.2 or higher. HTTPS is enforced across the entire platform. Any request over unencrypted HTTP is automatically redirected to HTTPS. TLS certificates are managed and rotated automatically via AWS Certificate Manager.

Document Storage (AWS S3)

Fleet documents, registration files, and other uploads are stored in AWS S3 with server-side encryption (SSE-S3) enabled by default. Bucket policies restrict public access entirely. Objects are only accessible via signed, time-limited URLs generated at the application layer for authenticated users.

Network Isolation

DOCKEX backend services operate within a Virtual Private Cloud (VPC) with security groups configured to allow only necessary traffic. Database instances are not publicly accessible and accept connections only from application-tier services within the same VPC.

Authentication

User passwords are never stored in plaintext. DOCKEX hashes all passwords using bcrypt with an appropriate work factor before storage. Authentication tokens are short-lived, cryptographically signed JWTs. Tokens are invalidated on logout and expire automatically after a defined inactivity period.

Role-Based Access Control (RBAC)

The platform enforces a multi-tier RBAC model for fleet operators and administrators. Each role carries a distinct permission set enforced at the API layer. Fleet operators can only access data belonging to their own organization. Administrators operate under additional audit controls.

Session Management

Sessions are server-validated on every authenticated request using short-lived JWTs (15-minute access tokens). Refresh tokens carry a 7-day expiry and are validated server-side on every renewal. Failed authentication attempts are tracked per account. After 5 consecutive failures, accounts are automatically locked for 30 minutes to protect against brute-force attacks. Login IP addresses are recorded with each session for audit purposes.

Security Headers

DOCKEX configures HTTP security headers on all responses to mitigate common browser-based attack vectors:

• X-Frame-OptionsPrevents clickjacking by blocking iframe embedding from unauthorized origins.
• X-Content-Type-OptionsDisables MIME-type sniffing, preventing content-type confusion attacks.
• Referrer-PolicyControls the referrer information included in outgoing requests to avoid leaking sensitive URL parameters.
• Permissions-PolicyRestricts access to browser APIs such as camera, microphone, and geolocation to only what is required.

Input Validation and Injection Prevention

All user-supplied input is validated and sanitized server-side. The NestJS backend uses Drizzle ORM for all database access. All queries are fully parameterized and user input is never interpolated directly into SQL statements. API inputs are validated against strict schemas using class-validator with whitelist enforcement, rejecting any fields not explicitly declared in the DTO before reaching business logic.

DOCKEX uses Stripe as its exclusive payment processor. Stripe is a PCI DSS Level 1 Service Provider (the highest attainable level of PCI compliance), validated annually by a Qualified Security Assessor (QSA).

Stripe's Security Certifications

• PCI DSS Level 1 Service Provider
• SOC 1 Type II and SOC 2 Type II
• ISO 27001 certified
• Annual penetration testing by independent third parties

For full details on Stripe's security posture, see stripe.com/docs/security.

In Transit

Every connection to DOCKEX APIs, web applications, and internal services uses TLS 1.2 or TLS 1.3. Cipher suites are configured to prefer forward secrecy (ECDHE key exchange), ensuring that a future compromise of the server's private key cannot be used to decrypt previously captured traffic. Weak or deprecated cipher suites are explicitly disabled.

At Rest

DOCKEX uses AWS-managed encryption for data at rest across all storage layers:

• PostgreSQL databases:Hosted on AWS RDS with encryption at rest enabled using AES-256. Automated backups are encrypted using the same key policy.
• Document storage (S3):All objects in DOCKEX S3 buckets are encrypted at rest using SSE-S3 (AES-256), applied by AWS to every object on write.
• Application logs:Application logs are written to AWS CloudWatch Logs with server-side encryption enabled.

Password Storage

User passwords are hashed using bcrypt with a cost factor tuned to remain computationally expensive on modern hardware. Plaintext passwords are never written to logs, databases, or any persistent storage. Password reset flows use cryptographically random, time-limited single-use tokens.

Principle of Least Privilege

Every system component (application services, database roles, S3 bucket policies, and IAM roles) is granted only the permissions required to perform its designated function. Application database access uses least-privilege roles, and schema changes run only through a controlled migration step at deploy time. S3 service accounts can only write to specific bucket prefixes. IAM roles are scoped to individual services and do not share credentials.

Internal Employee Access

Production data access is restricted to the founder and any authorized personnel with a legitimate operational need. All production access requires individual authentication. Shared credentials are not permitted. Access is reviewed periodically, and permissions are revoked promptly upon role change or departure.

Multi-Tenant Isolation

DOCKEX is a multi-tenant platform. Each organization's data is logically isolated at the database level using tenant-scoped identifiers enforced at the application layer on every query. There is no pathway for one tenant to access another tenant's data through the application.

Authentication Token Management

Authentication tokens are generated with cryptographically secure random generators and carry expiration timestamps. Tokens are invalidated on logout and expire automatically after a defined inactivity period. Session tokens cannot be reused after invalidation.

Detection

DOCKEX operates continuous monitoring across application logs and infrastructure metrics. Anomalous access patterns, elevated error rates, and unusual authentication activity generate automated alerts to the founder. Admin actions are recorded in a persistent audit log (including the action taken, IP address, and timestamp), providing a full trail of privileged operations within the platform.

Response

Upon identifying a potential security incident, the DOCKEX team follows a structured response process: contain the issue to prevent further impact, investigate root cause and scope, remediate the vulnerability, and conduct a post-incident review. Affected systems may be isolated or rolled back as warranted by the severity of the incident.

Customer Notification

If a security incident results in unauthorized access to customer data, DOCKEX will notify affected customers without undue delay and in accordance with applicable law. Notifications will include a description of what occurred, the categories of data involved, the steps we have taken in response, and recommended actions for affected users.

Notifications will be sent to the email address on file for the affected organization. Critical notifications may also be surfaced within the DOCKEX application.

DOCKEX operates a responsible disclosure program. If you discover a security vulnerability in our platform, we encourage you to report it to us privately so we can investigate and remediate it before it is exploited.

Our Commitments

• We will acknowledge receipt of your report within 3 business days.
• We will provide an initial assessment of severity and scope within 10 business days of receipt.
• We will work to remediate confirmed vulnerabilities in a timeframe proportionate to their severity.
• We will keep you informed of our progress and notify you when the issue has been resolved.
• We ask that you avoid accessing, modifying, or deleting data belonging to other users during your research, and that you refrain from public disclosure until we have addressed the issue.

DOCKEX does not currently offer a bug bounty program, but we genuinely appreciate responsible security research and will acknowledge contributions where the reporter consents.

DOCKEX reviews and updates this Security page as our practices evolve. Material changes (such as the adoption of new encryption standards, changes to our infrastructure providers, or updates to our incident response procedures) will be reflected here with an updated effective date.

We may notify customers of significant changes via email or in-app notification. Continued use of the platform after an update constitutes acknowledgment of the revised security practices.