Security Policy

Effective Date: June 30, 2026  |  Last Updated: July 4, 2026

Middledoc is built to handle sensitive professional documents — tax records, legal files, HR data, healthcare paperwork. Security is foundational to our product, not an afterthought. This page describes the security controls, practices, and commitments we maintain to protect your data.

1. Encryption

1.1 Data in Transit

All data transmitted between your browser and Middledoc servers is encrypted using TLS 1.3 (Transport Layer Security). We enforce HTTPS across all endpoints. HTTP connections are automatically redirected to HTTPS. Older TLS versions (1.0, 1.1) and weak cipher suites are disabled. Our TLS configuration is validated against current industry standards.

1.2 Data at Rest

All documents and files stored in Middledoc are encrypted at rest using AES-256 encryptionon Cloudflare R2 object storage. Cloudflare R2 uses server-side encryption (SSE) with AES-256 keys managed through Cloudflare's key management infrastructure.

Database records are stored on encrypted volumes. Encryption keys are managed separately from the data they protect.

1.3 Password Storage

User passwords are never stored in plaintext. All passwords are hashed using bcrypt with an appropriate cost factor before storage. We cannot retrieve your plaintext password and neither can anyone who gains access to our database.

1.4 Authentication Tokens

Session authentication uses JSON Web Tokens (JWT) stored exclusively in httpOnly, Secure, SameSite=Strict cookies. JWT tokens cannot be accessed via JavaScript, making them immune to cross-site scripting (XSS) token theft. Tokens have defined expiry times and are invalidated on logout.

2. Infrastructure Security

2.1 Hosting — Render

Middledoc's application servers and background job processors run on Render (render.com), a managed cloud platform that provides:

• Isolated compute environments per service
• Automatic TLS certificate management and renewal
• Private networking between internal services
• Continuous deployment with rollback capability
• SOC 2 Type II compliance at the infrastructure layer

2.2 Network Security — Cloudflare

All traffic to middledoc.com passes through Cloudflare's global network before reaching our application servers. Cloudflare provides:

• Web Application Firewall (WAF): Protection against OWASP Top 10 vulnerabilities including SQL injection, XSS, and CSRF
• DDoS protection: Anycast network absorbs and mitigates volumetric DDoS attacks at the network edge
• Bot management: Detection and blocking of malicious automated traffic
• Rate limiting: Configurable request rate limits per IP and endpoint
• API Shield: Schema validation and anomaly detection for API endpoints
• TLS termination: Industry-leading TLS configuration at the edge

2.3 Document Storage — Cloudflare R2

Uploaded documents are stored in Cloudflare R2object storage. Documents are not publicly accessible — all access is authenticated and authorized through the Middledoc API. Pre-signed download URLs expire within a short time window (5 minutes) and are generated per-request. Files are stored with AES-256 encryption and Cloudflare's infrastructure-level redundancy.

2.4 Database Security

Middledoc's PostgreSQL database:

• Accepts connections only over encrypted TLS channels
• Is not directly exposed to the public internet
• Uses connection pooling with configured pool limits to prevent resource exhaustion
• Has automated backup with point-in-time recovery capability
• Is protected by network-level firewall rules restricting access to authorized application servers only

3. Access Controls

3.1 Application-Level RBAC

Middledoc enforces role-based access control (RBAC) at the API level:

• Owner: Full access to all organization data, billing, and team management
• Admin: Full access to clients, documents, and requests; can manage team members
• Member: Access restricted to assigned clients and groups only; cannot access clients outside their assignments

Every API request is authenticated and authorization is checked before any data is returned. There are no “publicly readable” endpoints for authenticated user data. Client portal access uses separate, one-time or time-limited share tokens that are scoped to specific document requests only.

3.2 Admin Panel Isolation

The Middledoc administrative panel (for Middledoc staff only) is a separate application with separate authentication, separate JWT audience scoping, and 8-hour session limits. Admin credentials are distinct from user-facing credentials.

3.3 Production System Access

Access to Middledoc's production infrastructure is restricted to authorized personnel. Multi-factor authentication (MFA) is required for all production system access. We apply the principle of least privilege — personnel are granted only the minimum permissions required to perform their duties.

3.4 Audit Logging

Middledoc maintains an audit log of significant account events including:

• Login and logout events
• Document uploads, downloads, deletions, and rejections
• E-signature events
• User and team management changes
• Billing and plan changes
• API access by admin users

Audit logs use append-only audit logging with timestamped entries and are retained per configurable retention policy. Account holders on paid plans can view their audit log from the admin panel.

4. Application Security

4.1 OWASP Top 10 Protection

Our development practices and infrastructure controls address the OWASP Top 10 web application security risks:

• Injection (SQL, command): Parameterized queries and ORM use throughout; no string-concatenated SQL
• Broken authentication: httpOnly JWT cookies; bcrypt password hashing; brute-force rate limiting
• Sensitive data exposure: TLS 1.3 in transit; AES-256 at rest; no sensitive data in URLs or logs
• XSS: Output encoding; Content Security Policy headers; httpOnly cookies prevent token theft
• CSRF: SameSite=Strict cookies; CSRF token validation on state-changing requests
• Security misconfiguration: Regular security audits; automated dependency scanning
• Broken access control: RBAC enforced at API layer for every request
• Insecure deserialization: No use of unsafe deserialization methods
• Using components with known vulnerabilities: Automated dependency vulnerability scanning in CI/CD
• Insufficient logging: Comprehensive audit logs with alerting

4.2 File Upload Security

Uploaded files are processed through the following security controls:

• File size limits enforced per upload and per account plan
• MIME type validation (both header and content-based)
• Uploaded files are stored in isolated object storage, not served from the same origin as the application
• File contents are not executed; they are stored as binary data and downloaded only

4.3 Security Headers

Middledoc sets the following HTTP security response headers:

• Strict-Transport-Security (HSTS) — enforces HTTPS
• X-Content-Type-Options: nosniff — prevents MIME sniffing
• X-Frame-Options: DENY — prevents clickjacking
• Content-Security-Policy — restricts content sources
• Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy — restricts browser feature access

5. Data Isolation and Multi-Tenancy

Middledoc is a multi-tenant SaaS application. Customer data is logically isolated:

• Every database query is scoped to the authenticated user's organization using a tenant ID filter enforced at the API level
• Cross-tenant data access is architecturally prevented — an account holder cannot retrieve or enumerate another account holder's clients, documents, or metadata
• Team member access within an organization is further restricted by group assignments enforced at every data retrieval endpoint
• Client portal share tokens are one-time or expiring tokens that are scoped to a single document request, not to an entire account

6. Incident Response

6.1 Detection

We monitor our systems for anomalous activity using server-side log analysis and infrastructure-level alerts. Cloudflare provides real-time threat detection at the network edge.

6.2 Response

Middledoc maintains a documented incident response plan. Upon detection of a potential security incident:

1. Triage: Assess the nature, scope, and severity of the incident
2. Containment: Isolate affected systems or accounts to prevent further impact
3. Investigation: Determine the root cause and extent of any data exposure
4. Remediation: Fix the vulnerability and restore service
5. Notification: Notify affected users and, where required by law, regulatory authorities. For personal data breaches, affected customers are notified within 72 hours of confirmed impact on their data
6. Post-incident review: Document lessons learned and implement preventive measures

6.3 Business Continuity

Our infrastructure is designed for resilience. We maintain automated database backups with regular restoration testing. Application deployments use zero-downtime strategies. Incident playbooks are maintained for common failure scenarios.

7. Vulnerability Disclosure Program

Middledoc welcomes responsible security research. If you believe you have found a security vulnerability in our platform, please report it to us before public disclosure.

7.1 How to Report

Please include in your report:

• A description of the vulnerability and its potential impact
• Step-by-step instructions to reproduce the issue
• Any proof-of-concept code (please do not exploit data belonging to other users)
• Your contact information for follow-up

7.2 Our Commitment to Reporters

• We will acknowledge receipt of your report within 3 business days
• We will provide an initial assessment within 10 business days
• We will keep you informed of our progress in addressing the issue
• We will not take legal action against researchers who comply with this responsible disclosure policy
• We will credit reporters in our changelog (with your permission)

7.3 Out of Scope

The following are outside the scope of our vulnerability disclosure program:

• Social engineering or phishing attacks against Middledoc employees or users
• Physical security issues
• Denial of service attacks
• Scanning or testing without prior authorization that affects service availability
• Vulnerabilities in third-party services we use that are the responsibility of those service providers
• Reports that require access to another user's account without their consent

8. Third-Party Security

We assess the security practices of all significant third-party service providers before engaging them. Key providers relevant to data security:

• Cloudflare: SOC 2 Type II, ISO 27001 certified. Provides edge security, WAF, and storage.
• Render: SOC 2 Type II certified hosting provider.
• OpenAI: Processes document content for AI classification under API data handling terms that restrict training use.
• Anthropic: Processes document content for AI classification under equivalent API data handling terms.
• SendGrid (Twilio): ISO 27001 and SOC 2 Type II certified email delivery provider.
• Stripe: PCI DSS Level 1 certified payment processor. Payment data never touches Middledoc servers.

8a. FTC Safeguards Rule (GLBA)

Middledoc supports mortgage brokers and financial professionals subject to the FTC Safeguards Rule. Customer documents are encrypted at rest (AES-256 via Cloudflare R2), encrypted in transit (TLS 1.3), access-controlled per account, and subject to configurable retention policies. Multi-factor authentication is available for all accounts.

8b. Data Retention

Document retention is configurable per request. Completed requests can be set to auto-delete documents after a specified period (30, 60, 90, 180, or 365 days). E-signature audit trails are retained for 7 years per ESIGN Act requirements. Activity logs are retained for the duration of the account relationship.

8c. Nigeria Data Protection Act (NDPA)

Skillhanger Limited is registered in Nigeria (RC 1711272) and processes data in compliance with the Nigeria Data Protection Act 2023. Personal data is processed lawfully, stored securely, and subject to data subject access and deletion rights.

9. Compliance Roadmap

Middledoc is committed to continuous improvement of our security posture. Our current and planned compliance milestones:

10. Security Best Practices for Users

You can further protect your Middledoc account by following these practices:

• Use a strong, unique password for your Middledoc account (minimum 12 characters with a mix of letters, numbers, and symbols)
• Do not share your password or account credentials with others
• Log out of your account when using shared or public computers
• Be cautious of phishing emails claiming to be from Middledoc — we will never ask for your password by email
• Review your team member access settings regularly and remove access for departed employees promptly
• Contact us immediately if you suspect unauthorized access to your account

11. Security Contact

For security questions, vulnerability reports, or HIPAA BAA requests:

We take all security reports seriously and will respond as quickly as possible.