Security-First API Backend for Mobile Applications

The Challenge

Mobile API backends have a fundamentally different security profile than server-to-server APIs. The client is untrusted, runs on hardware you don't control, can be decompiled by adversaries, and communicates over networks that may be intercepted. Every API endpoint you expose is potentially accessible to an attacker who has reverse-engineered the app binary — meaning your backend must validate everything, trust nothing from the client, and assume that any client-side security control can be bypassed.

Authentication in mobile contexts is complicated by the need to balance security with user experience. Users who are forced to re-authenticate too frequently abandon apps; users whose sessions never expire have their accounts compromised by stolen devices. Token rotation, background refresh, and graceful re-authentication flows are engineering problems that have security consequences if implemented incorrectly — a leaked refresh token that works indefinitely is functionally equivalent to a leaked password.

Scalability and security are frequently in tension in API design. Rate limiting at the right granularity (per-user, per-IP, per-endpoint) requires Redis or a similar shared state layer and adds latency. Structured logging that enables incident response requires more code than unstructured print statements. Input validation that prevents injection attacks requires schema libraries and error handling. We make these engineering investments upfront, because retrofitting them into an existing API with active users is significantly more expensive and risky than building them in from the start.

Signs You Need This

• You're building a mobile app that handles user accounts, transactions, or any personal data
• Your current API returns raw database errors or stack traces in HTTP responses
• You have no structured logging — incidents would require reading through raw application logs
• Authentication tokens don't expire or are shared across all environments with the same signing key
• Input validation is done only in the mobile app, with no server-side schema validation
• There's no rate limiting on authentication endpoints — a bot could try millions of passwords undetected

How We Approach It

import { z } from 'zod';

// Strict schema — unknown fields are stripped automatically
export const CreateUserSchema = z.object({
  email: z.string().email().max(255).toLowerCase(),
  password: z
    .string()
    .min(12, 'Password must be at least 12 characters')
    .regex(/[A-Z]/, 'Must contain uppercase')
    .regex(/[0-9]/, 'Must contain a digit')
    .regex(/[^a-zA-Z0-9]/, 'Must contain a special character'),
  displayName: z.string().min(1).max(100).trim(),
  // role intentionally excluded — assigned server-side, never from client
}).strict();   // .strict() rejects any extra fields (prevents mass assignment)

export type CreateUserInput = z.infer<typeof CreateUserSchema>;

// In the route handler:
app.post('/v1/users', async (req, res) => {
  const result = CreateUserSchema.safeParse(req.body);
  if (!result.success) {
    return res.status(400).json({
      error: 'Validation failed',
      details: result.error.flatten().fieldErrors,
      // Never return the raw Zod error — it may leak schema details
    });
  }
  const validatedInput = result.data;  // Type-safe, stripped unknown fields
  // ... create user with validatedInput
});

Redis Sliding Window Rate Limiter

Fixed-window rate limits are bypassed by timing requests at window boundaries. We use a sliding window implemented with a Redis sorted set — accurate, atomic, and horizontally scalable:

import { redis } from '../lib/redis';

interface RateLimitOptions {
  windowMs: number;   // sliding window duration in ms
  max: number;        // max requests in the window
  keyPrefix: string;
}

export async function slidingWindowRateLimit(
  identifier: string,  // user ID or IP — never trust client X-Forwarded-For
  opts: RateLimitOptions
): Promise<{ allowed: boolean; remaining: number; resetIn: number }> {
  const now = Date.now();
  const windowStart = now - opts.windowMs;
  const key = `${opts.keyPrefix}:${identifier}`;

  const pipeline = redis.pipeline();
  // Remove requests outside the sliding window
  pipeline.zremrangebyscore(key, 0, windowStart);
  // Count requests in current window
  pipeline.zcard(key);
  // Add current request with timestamp as score
  pipeline.zadd(key, now, `${now}-${Math.random()}`);
  // Set TTL to window duration (auto-cleanup)
  pipeline.pexpire(key, opts.windowMs);

  const results = await pipeline.exec();
  const currentCount = (results[1][1] as number);

  if (currentCount >= opts.max) {
    return { allowed: false, remaining: 0, resetIn: opts.windowMs };
  }
  return { allowed: true, remaining: opts.max - currentCount - 1, resetIn: opts.windowMs };
}

// Usage on login endpoint — strict 5 attempts per 15 minutes per user identity
app.post('/v1/auth/login', async (req, res) => {
  const { email } = req.body;
  const limit = await slidingWindowRateLimit(email, {
    windowMs: 15 * 60 * 1000,
    max: 5,
    keyPrefix: 'login'
  });
  if (!limit.allowed) {
    return res.status(429).json({ error: 'Too many login attempts. Try again later.' });
  }
  // ... proceed with authentication
});

Tools We Use

Our stack choices prioritize type safety, security-by-default library choices, and operational observability.

Common Mistakes We Prevent

• Returning raw database errors or ORM exceptions in API responses — error messages that include table names, column names, or stack traces are a free reconnaissance gift to attackers mapping your data model
• Using the same JWT signing key across all environments — a key leaked from a staging or CI environment is also the production signing key, enabling token forgery in production
• Implementing rate limiting at the application layer without Redis shared state — each instance of a horizontally scaled API maintains its own in-memory counter, so a limit of "100 requests per minute" with 10 instances is effectively 1,000 requests per minute
• Logging request payloads wholesale without a sensitive field redaction layer — a single log line containing a user's password or payment token is a compliance violation and a security incident waiting to happen

What You Get

• Production-ready API backend with documented security architecture and threat model
• Asymmetric JWT authentication with per-environment signing keys, rotation procedures, and refresh token families
• Schema-validated request handling with sensitive field stripping and parameterized database queries
• Redis-backed rate limiting with sliding window algorithm and per-endpoint configuration
• Structured JSON logging with sensitive field redaction and CloudWatch Insights query library
• AWS API Gateway integration with WAF rules and throttling configuration
• Security test report and handover documentation including operational runbook

Timeline & What to Expect

After handover, your team owns the full codebase with comprehensive documentation of every security decision and why it was made. We provide a 30-day support window for questions, and we're available for a follow-up security review after 6 months as the API has grown with real usage patterns that may surface new requirements.

Frequently Asked Questions

When This Is the Right Fit

This engagement is right for you if you're building a new mobile app backend from scratch and want to avoid the expensive security retrofit that typically happens 6–12 months post-launch, or if you have an existing backend that has grown organically and has known security gaps (missing input validation, no rate limiting, unstructured logs) that you want to address systematically before a major user growth phase or compliance audit.

This is not the right fit if you need a fully managed backend service (Firebase, Supabase, AWS Amplify) rather than a custom API. Managed services have their own security properties and limitations — we can advise on configuration and security review of those platforms, but building on top of a managed service is a different engagement than building a custom backend from scratch.