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-Timestampheader 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-Signatureare stripped from all stored logs viaLog_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.
Leave a Reply