Back to Main Site

Production-Grade API Security for Your Perfex CRM

Last updated on Jul 30, 2026 2:02 AM 2:02 AM 397.46 ms

APIs Without Security Are Data Breaches Waiting to Happen

Adding an API to your CRM means exposing your business data to the internet. Client records, financial data, internal metrics - all accessible via HTTP requests.

Most CRM API modules treat security as an afterthought: a single API key, maybe basic rate limiting. That’s not enough for production use. Not when your clients’ personal data is on the line.

Data Builder takes a different approach. Security isn’t a feature we added later. It’s the foundation the entire API is built on.

6-Stage Middleware Pipeline

Every API request passes through six security layers before reaching your data. Each layer can reject the request independently:

Stage 1: DDoS Shield

The first line of defense, before any authentication:

  • Body size limit: Requests exceeding 256KB are rejected immediately (413)

  • Global IP throttle: Per-IP rate limiting prevents brute-force attacks

  • Malformed payload detection: JSON nesting deeper than 10 levels or oversized query strings are blocked (400)

  • Execution timeout: Requests exceeding 10 seconds are terminated

Stage 2: CORS Guard

Cross-origin request control with two phases:

  • Preflight (OPTIONS): Server-level policy - responds without requiring authentication (browsers don’t send credentials in preflight)

  • Post-auth whitelist: Per-token domain restriction - only allowed origins can make API calls

Stage 3: Auth Gate

Token verification with cryptographic best practices:

  • SHA-256 hash-only storage: Plaintext tokens are NEVER stored in the database

  • Timing-attack safe comparison: Uses hash_equals() - not ===

  • HMAC-SHA256 signing (optional): Verify request integrity with canonical signing (method + path + query + body digest + timestamp)

  • Anti-replay protection: X-Timestamp header with 300-second window

Stage 4: Rate Limiter

Per-token request throttling:

  • Fixed-window counter with atomic UPSERT (no race conditions)

  • Fail-closed: If the rate limit database is unavailable, requests are denied (503) - never allowed through

  • Response headers: X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After

Stage 5: Scope Verifier

Fine-grained access control:

  • Table-level permissions: Per-table read/create/update/delete matrix

  • View-level restrictions: Token can be limited to specific saved views

  • CIDR IP matching: Lock tokens to specific IP ranges

  • Write enforcement: POST→create, PUT→update, DELETE→delete permission mapping

Stage 6: Request Logger

Complete audit trail:

  • Two-phase logging: Start in middleware, finalize after controller (includes status code + response time)

  • Sensitive field redaction: token, Authorization, X-Signature are stripped from all stored logs via Log_redactor

OWASP Security Headers

Every API response - success, error, or middleware rejection - includes standard security headers:

Header Value Protection
X-Content-Type-Options nosniff Prevents MIME-sniffing attacks
X-Frame-Options DENY Prevents clickjacking via iframe
Referrer-Policy strict-origin-when-cross-origin Prevents API path/token leaks
X-XSS-Protection 0 Disables deprecated XSS Auditor
Cache-Control no-store, no-cache, must-revalidate Prevents data caching
Pragma no-cache HTTP/1.0 cache prevention

These are applied automatically from a single control point - _set_standard_headers(). No configuration needed.

Sensitive Table Protection: 6 Independent Layers

Critical tables (tblstaff, tblcontacts, tbloptions, tbldata_builder_api_tokens) are protected by six independent enforcement mechanisms:

Even if one layer fails, the remaining five still protect your data. Defense in depth.

Sandbox PII Randomization

The API Explorer‘s sandbox mode includes pattern-based PII randomization for 25+ sensitive column types:

  • Email addresses → randomized @example.com

  • Phone numbers → randomized format

  • Names → synthetic names

  • Addresses → randomized locations

  • And more…

This applies to both REST sandbox responses and recursive GraphQL tree sanitization - so developers can test query structures without exposing real customer data.

GraphQL-Specific Protections

Control Purpose
Query Depth limit (max 5) Prevent deeply nested resource-exhaustion queries
Complexity scoring Custom per-field complexity functions
Introspection disabled External tokens cannot discover your schema
JSON array body rejection Prevent multi-query batching attacks (OWASP API2:2023)

Zero Compromise Security

Data Builder’s security isn’t a checkbox feature. It’s a production-grade security architecture designed for enterprises that take data protection seriously.

6 middleware stages. OWASP headers. HMAC signing. PII protection. Defense in depth.

Your API is only as strong as its weakest endpoint. We don’t have one.