Last reviewed: 14 August 2026.

Security is designed into every KiloDrive journey

KiloDrive protects identity, location, trip, delivery, driver, vehicle, financial, communication, and support information through multiple independent safeguards across the mobile app, API, administration portal, storage, database, and operational infrastructure. This defence-in-depth approach means that other controls continue to protect the service if one layer is unavailable or bypassed.

Security is a continuing process. KiloDrive combines prevention, detection, auditable response, recovery procedures, and privacy rights. No organization can honestly promise that a system is impossible to compromise, but KiloDrive is designed to reduce the likelihood and impact of misuse and to preserve evidence for investigation and recovery.

1. Information protected

  • Identity, verified contacts, authentication methods, roles, devices, sessions, and security events.
  • Ride, delivery, rental, route, offer, stop, status, GPS, safety, rating, and dispute records.
  • Identity documents, photographs, vehicle registration, insurance, fitness, and business evidence.
  • Wallet balances, holds, ledger entries, top-ups, memberships, refunds, cashouts, reconciliation, and fraud review.
  • Notifications, in-trip chat, call metadata, consented recordings where enabled, support tickets, and case evidence.

2. Encrypted connections and hardened websites

Production services use HTTPS to encrypt information in transit. HTTP Strict Transport Security keeps compatible browsers on HTTPS. The portal and corporate website send controls against content-type guessing and framing, restrict referrer information, and use a Content Security Policy that limits where executable and visual resources may load from.

Public forms use request limits and Cloudflare Turnstile where configured. Proxy-aware processing recognizes validated Cloudflare forwarding headers instead of blindly trusting user-supplied network headers.

3. Identity and access security

  • Passwords: PBKDF2-SHA256 with a unique random salt and constant-time verification. Plaintext passwords are not retained.
  • Tokens: short-lived access tokens signed with RS256. Only public verification material is published; the private key is stored outside the deployed application under operating-system access controls or an approved secret provider.
  • Rotation: refresh tokens rotate, sessions can be revoked, and signing keys support a controlled public-key rollover.
  • Additional verification: time-based 2FA with QR enrollment and recovery codes, passkeys, verified email or phone codes, and verified social-provider identity tokens.
  • Abuse resistance: stricter limits and lockout controls protect login, 2FA, password reset, voucher redemption, and other sensitive operations.
  • Least privilege: riders, drivers, rental teams, tenant administrators, and system administrators receive only role-appropriate permissions.

4. Mobile-app security

Authentication material is stored in platform protected secure storage rather than normal application preferences. Optional app lock uses device biometrics. Permissions for location, camera, photos, microphone, notifications, and biometrics are requested only when a chosen feature needs them, with education and settings recovery after denial.

Firebase App Check can verify selected sensitive calls using Play Integrity on Android and App Attest or DeviceCheck on iOS. The authenticated server profile, not a local role preference, determines the workspaces a user may enter.

5. Protected API processing

Protected API calls pass through tenant resolution, rate limiting, authentication, authorization, validation, and centralized exception handling. Tenant query filters isolate tenant data. Privileged cross-tenant operations require explicit context, additional authorization, and audit records.

Request limits reduce resource exhaustion. Structured errors do not expose stack traces or secrets. UUIDv7 identifiers prevent predictable enumeration of exposed transactional records.

High-risk mutations require idempotency keys. Concurrent duplicates are rejected while processing, completed retries replay the original response, and payload changes under the same key are rejected. This reduces duplicate charges, cashouts, settlements, and lifecycle changes during network retries.

6. Database and country isolation

The control database holds the single global identity, authentication state, security audit, country directory, and central settings. Country cells hold local trips, deliveries, rentals, wallets, payments, escrow, notifications, and domain audit. Application routing and database filters enforce country and tenant boundaries.

Settlement stays inside the responsible country cell so matching wallet debits and credits do not depend on a cross-database transaction. Database credentials are never returned to clients. Schema changes are reviewed MySQL scripts, allowing operators to inspect the exact change before deployment. Backup, restoration, reconnect, and incident runbooks support recovery.

7. Financial integrity

  • Amounts use integer minor units and explicit ISO currency codes instead of floating point.
  • Wallet movements use immutable referenced ledger rows and deterministic lock order inside short transactions.
  • Held funds are separated from spendable funds for preauthorization, escrow, and pending cashout.
  • Authenticated provider webhooks are idempotent and unknown results are reconciled before an unsafe retry.
  • Velocity, cooldown, device-linkage, duplicate, and fraud rules can block or refer suspicious activity for review.
  • Voucher codes use keyed hashing, one-time redemption, attempt limits, and temporary lockouts rather than plaintext storage.
  • KiloDrive does not store raw card credentials or full payout destinations; payment providers process cards and KiloDrive keeps references and masked descriptions.

8. Private document storage

Identity and vehicle evidence is kept outside the public website. Uploads accept approved PDF, JPEG, and PNG signatures, are limited to 10 MB, use randomized object names, and remain private. S3 objects use server-side AES-256 or AWS KMS encryption. Optional malware scanning can quarantine a file before review. Access, review, expiry, and administrative decisions are authorized and auditable.

9. Location, chat, and calling

Realtime data is authorized to the relevant participants. In-trip chat is restricted to the assigned rider and driver during an active trip and closes at completion or cancellation. Private chat content is excluded from operational logs.

Live location uses an in-memory service for proximity and controlled persistence for active-trip safety replay or investigation. Trip sharing uses time-limited opaque references. Voice rooms use short-lived room credentials and include ring timeout and cancellation. Recording occurs only when the required service, policy, notice, consent, private storage, retention, and audit configuration are active.

10. Auditing without secret leakage

Correlation identifiers connect API requests, outbox work, notifications, webhooks, and realtime events. Logs deliberately exclude passwords, tokens, one-time codes, private keys, payment details, raw payout data, private chat content, and document bodies. Important user and administrator actions record actor, time, result, device or browser context, and proxy-aware IP information where appropriate.

11. Reliable providers and background work

External side effects use a durable transactional outbox. The business change and first outbox record are committed together. Workers use leases, heartbeats, bounded retries, stale-claim recovery, retention, and operator recovery tools. Provider calls use timeouts and safe circuit-breaker behavior. Non-idempotent calls are not automatically repeated without a stable provider key and outcome reconciliation.

12. Monitoring and incident response

Readiness checks cover required database, cache or location, workers, outbox, reconciliation, and configured providers. Metrics cover latency, errors, rate-limit rejection, outbox lag, webhook failure, notification failure, wallet reconciliation, and worker heartbeat without collecting private payloads.

Runbooks address stuck work, payment outages, signing-key rotation, tenant suspension, database restoration, fraudulent cashouts, and other high-impact events. Alerts route provider, worker, and financial failures to authorized operators.

13. Privacy, retention, and user control

KiloDrive provides data export and account-deletion request workflows. Deletion is coordinated centrally while each country cell completes its own anonymization checkpoint. Eligible personal fields are anonymized while financial, tax, fraud, safety, dispute, and legal records are retained only when a lawful obligation or defensible need applies.

Users can manage sessions, contact details, notification preferences, social sign-ins, privacy choices, and trusted contacts. Applicable access, correction, objection, portability, deletion, and complaint rights are described in the Privacy Policy.

14. A shared responsibility

Use a unique password, enable 2FA or a passkey, protect recovery codes, keep the device updated, review active sessions, verify the driver and vehicle, and never share a password or one-time code. KiloDrive support will not request a password, complete card number, private key, or authentication code.

Report suspected compromise, privacy concerns, unsafe trips, fraud, or security issues through in-app support or Contact Us. For immediate danger, contact local emergency authorities first. KiloDrive is not an emergency service.

15. Continuing commitment

KiloDrive reviews controls as the platform, threats, technology, and legal obligations evolve. Material changes are reflected here and in the Privacy Policy. Responsible vulnerability reports can be submitted through Contact Us without including live credentials, private user data, or destructive test results.