DEV Community: Marco Cheung

Server-Side Rendering: The Security Reality Check Every Developer Needs

Marco Cheung — Wed, 10 Sep 2025 20:53:59 +0000

Server-Side Rendering (SSR) has become increasingly popular for its performance benefits and SEO advantages. However, there's a dangerous misconception in the developer community: SSR is often mistakenly viewed as a security solution. Let's dive deep into what SSR actually protects and, more importantly, what it doesn't.

The SSR Security Misconception

Many developers believe that because SSR processes data on the server, it automatically makes their applications more secure. This leads to dangerous assumptions like:

"If I check feature flags server-side, they're secure"
"SSR-embedded config can't be tampered with"
"Server-rendered auth checks protect my app"

These assumptions can create serious security vulnerabilities.

What SSR Actually Does for Security

✅ 1. Keeps Server Secrets Server-Side

SSR excels at keeping sensitive server-only data truly private:

// ✅ Server-side secrets (NEVER sent to client)
const serverSecrets = {
  databasePassword: process.env.DB_PASSWORD,
  apiKeys: process.env.THIRD_PARTY_API_KEY,
  jwtSecret: process.env.JWT_SECRET,
  encryptionKeys: process.env.ENCRYPTION_KEY
}

// ✅ Server-side processing with secrets
const authHeader = `Bearer ${process.env.INTERNAL_API_KEY}`
const response = await fetch('https://internal-api.company.com/data', {
  headers: { Authorization: authHeader }
})

Why this works: These secrets never leave the server environment and are never included in the client bundle or rendered HTML.

✅ 2. Eliminates Client-Side Config Fetches

SSR can embed configuration directly into the initial HTML, eliminating the need for additional API calls:

// ✅ Server embeds config during render
const configScript = `
  window.__APP_CONFIG__ = ${JSON.stringify({
    apiEndpoint: 'https://api.example.com',
    featureFlags: { newCheckout: true, darkMode: false }
  })};
`

// No separate XHR request needed - config available immediately

Benefits:

Faster initial page load
Reduced API server load
Better user experience (no loading states for config)

What SSR Does NOT Protect Against

Here's where the dangerous misconceptions begin. SSR fails to protect against several critical attack vectors:

❌ 1. Client-Side Data Tampering

The Problem: Anything rendered into the client is visible and modifiable.

<!-- ❌ This is visible in page source and modifiable at runtime -->
<script>
  window.__PRELOADED_STATE__ = {
    user: { role: 'admin', creditLimit: 10000 },
    features: { requireTwoFactor: true, skipValidation: false }
  };
</script>

Attack Example:

// Attacker opens DevTools console:
window.__PRELOADED_STATE__.user.role = 'admin'
window.__PRELOADED_STATE__.user.creditLimit = 999999
window.__PRELOADED_STATE__.features.skipValidation = true

// If client-side code trusts this data, security is compromised

❌ 2. Client-Side Security Logic Bypass

The Problem: Security decisions made in client-side JavaScript can be bypassed.

// ❌ DANGEROUS: Client-side security check
function submitPayment(amount, cardNumber) {
  const maxLimit = window.__PRELOADED_STATE__.user.creditLimit

  if (amount > maxLimit) {
    alert('Amount exceeds your credit limit!')
    return // ← Attacker can bypass this
  }

  // Process payment...
}

How attackers bypass this:

Runtime Modification:

// In DevTools console:
window.__PRELOADED_STATE__.user.creditLimit = 999999
// Now any amount will pass the check

Function Replacement:

// Replace the security function entirely:
window.submitPayment = function(amount, cardNumber) {
  // Skip all checks, go straight to payment
  processPaymentDirectly(amount, cardNumber)
}

DOM Manipulation:

// Modify form validation
document.querySelector('#payment-form').onsubmit = null
// Remove all client-side validation

❌ 3. Direct API Attacks

The Problem: Attackers can bypass your entire UI and call your APIs directly.

# ❌ Attacker discovers your API endpoints and calls them directly
curl -X POST https://yoursite.com/api/payment \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer stolen_or_manipulated_token" \
  -d '{
    "amount": 1,
    "currency": "USD", 
    "skipValidation": true,
    "userRole": "admin"
  }'

Common direct attack scenarios:

Payment amount manipulation
Feature flag bypassing
Role elevation
Validation skipping
Rate limit circumvention

❌ 4. Feature Flag Security Theater

This is particularly dangerous in modern applications:

// ❌ Client-side feature flag "security"
function handleSensitiveOperation() {
  const canAccess = window.__FEATURE_FLAGS__.adminAccess

  if (!canAccess) {
    showAccessDenied()
    return
  }

  performSensitiveOperation() // ← Can be bypassed
}

Why this fails:

Flags are visible in page source
Can be modified at runtime
Provide false sense of security
Don't protect the actual API endpoints

Real-World Attack Examples

Example 1: E-commerce Price Manipulation

// ❌ Vulnerable client-side pricing
window.__PRELOADED_STATE__ = {
  cart: {
    items: [{ id: 1, price: 100, quantity: 1 }],
    total: 100,
    discountEligible: false
  }
}

// Attacker modifies:
window.__PRELOADED_STATE__.cart.total = 1
window.__PRELOADED_STATE__.cart.discountEligible = true
// If server trusts client data, they pay $1 instead of $100

Example 2: Authentication Bypass

// ❌ Client-side auth state
window.__USER_STATE__ = {
  isAuthenticated: false,
  role: 'guest',
  permissions: ['read']
}

// Attacker escalates:
window.__USER_STATE__.isAuthenticated = true
window.__USER_STATE__.role = 'admin'
window.__USER_STATE__.permissions = ['read', 'write', 'delete']

Example 3: Two-Factor Authentication Skip

// ❌ Client-side 2FA flag
const requires2FA = window.__SECURITY_CONFIG__.twoFactorRequired

if (requires2FA) {
  showTwoFactorPrompt()
} else {
  proceedToSecureArea() // ← Attacker sets flag to false
}

The Correct Security Architecture

✅ Defense in Depth: Server-Side Validation

Golden Rule: Never trust the client for security decisions.

// ✅ SECURE: Server-side validation
app.post('/api/payment', authenticateUser, async (req, res) => {
  // 1. Server determines user's actual limits
  const user = await getUserFromDatabase(req.user.id)
  const actualCreditLimit = user.creditLimit

  // 2. Server validates against real data
  if (req.body.amount > actualCreditLimit) {
    return res.status(400).json({ 
      error: 'Amount exceeds credit limit',
      maxAllowed: actualCreditLimit 
    })
  }

  // 3. Server determines feature access
  const serverFeatureFlags = await getFeatureFlags(user)
  if (!serverFeatureFlags.paymentEnabled) {
    return res.status(403).json({ error: 'Feature not available' })
  }

  // 4. Process with server-side validation
  const result = await processPayment({
    amount: req.body.amount,
    userId: user.id,
    validatedLimits: actualCreditLimit
  })

  res.json(result)
})

✅ Client-Side: UX Only

Use client-side data purely for user experience, never for security:

// ✅ Client-side: UX hints only
function PaymentForm() {
  const suggestedLimit = window.__PRELOADED_STATE__.user.creditLimit

  return (
    <form onSubmit={handleSubmit}>
      <input 
        type="number" 
        placeholder={`Suggested max: $${suggestedLimit}`}
        // ↑ Just a UX hint, not enforced
      />
      <button type="submit">
        Pay Now
        {/* Server will validate everything */}
      </button>
    </form>
  )
}

async function handleSubmit(formData) {
  // Let server make all security decisions
  const response = await fetch('/api/payment', {
    method: 'POST',
    body: JSON.stringify(formData)
  })

  if (!response.ok) {
    // Handle server's security rejections
    const error = await response.json()
    showError(error.message)
  }
}

✅ Progressive Enhancement Pattern

Build your security assuming the worst:

// ✅ Assume client is compromised
const securePaymentFlow = {

  // 1. Client: Optimistic UX (can be bypassed)
  clientValidation: (amount) => {
    // Show immediate feedback for good UX
    // But never rely on this for security
    return amount > 0 && amount <= suggestedLimit
  },

  // 2. Server: Real validation (cannot be bypassed)
  serverValidation: async (userId, amount) => {
    const user = await db.users.findById(userId)
    const actualLimit = await calculateCreditLimit(user)

    if (amount > actualLimit) {
      throw new SecurityError('Amount exceeds verified limit')
    }

    return true
  },

  // 3. Payment processor: Final validation
  processPayment: async (validatedAmount, verifiedUser) => {
    // Triple validation at payment processor level
    return await paymentProvider.charge(validatedAmount, verifiedUser)
  }
}

Testing Your Security

Security Audit Checklist

❌ Vulnerable patterns to look for:

Client-side security decisions:

// DANGER: Security logic in client code
if (userRole === 'admin') { showAdminPanel() }
if (amount <= creditLimit) { processPayment() }
if (featureEnabled) { allowAccess() }

Trusting client data:

// DANGER: Server trusting client input
app.post('/api/action', (req, res) => {
  if (req.body.isAdmin) { // ← Never trust this
    performAdminAction()
  }
})

Security through obscurity:

// DANGER: Hiding instead of protecting
const hiddenApiKey = window.__CONFIG__.secretKey // ← Still visible

Penetration Testing Exercise

Test your own application:

Open DevTools → Console
Examine global variables: console.log(window)
Modify security-related data: Change user roles, limits, flags
Test if changes affect behavior: Can you bypass restrictions?
Try direct API calls: Use curl or Postman to bypass UI
Check network requests: Look for sensitive data in responses

If any of these tests reveal vulnerabilities, you have client-side security issues.

Best Practices Summary

✅ DO:

Use SSR for performance and UX
Keep secrets server-side only
Validate everything server-side
Treat client data as user input (untrusted)
Use defense in depth
Test with adversarial mindset

❌ DON'T:

Trust client-side security checks
Put security logic in JavaScript
Rely on "hidden" client data
Trust feature flags for access control
Skip server-side validation
Assume SSR = security

Conclusion

Server-Side Rendering is a powerful tool for performance and user experience, but it's not a security solution. The moment any data touches the client - whether through SSR, API calls, or client-side code - it should be considered compromised from a security perspective.

Remember: SSR can hide your secrets and improve performance, but it cannot protect your application from determined attackers. Security must be implemented server-side, with client-side code treated as purely cosmetic.

Build your applications assuming the client is hostile, validate everything server-side, and use SSR for what it's great at: delivering fast, SEO-friendly user experiences.

Security is not about making attacks impossible; it's about making them pointless because the server validates everything anyway.

Additional Resources

About the Author: This article is based on real-world experience building secure e-commerce applications with server-side rendering, including hands-on analysis of production SSR implementations and their security implications.

Defensive Programming: The Hidden Dangers of Spread Operators in Request Payloads

Marco Cheung — Thu, 21 Aug 2025 13:27:33 +0000

The Problem: When Convenience Becomes a Security Risk

The JavaScript spread operator (...) is one of the most convenient features in modern JavaScript and TypeScript. It allows us to easily merge objects, clone arrays, and pass multiple arguments to functions. However, when it comes to constructing request payloads—especially for APIs with strict schemas like GraphQL—the spread operator can become a dangerous tool that introduces runtime errors and security vulnerabilities.

The Spread Operator Trap

What Seems Convenient...

Consider this common pattern when building API request payloads:

// ❌ Dangerous: Using spread operator for payload construction
const createUserPayload = {
  ...userFormData,        // Contains: name, email, age, debugInfo, internalFlags
  ...additionalData,      // Contains: preferences, metadata, tempId
  ...featureFlags,        // Contains: enableBeta, debugMode, adminAccess
  operation: 'CREATE_USER'
}

// Send to GraphQL API
const result = await graphqlClient.mutate({
  mutation: CREATE_USER_MUTATION,
  variables: { input: createUserPayload }
})

...Can Break in Production

# GraphQL Schema only accepts these fields:
input CreateUserInput {
  name: String!
  email: String!
  age: Int
  preferences: UserPreferences
  operation: String!
}

Runtime Error:

GraphQL Error: Field "debugInfo" is not defined by type "CreateUserInput"
GraphQL Error: Field "internalFlags" is not defined by type "CreateUserInput"  
GraphQL Error: Field "tempId" is not defined by type "CreateUserInput"
GraphQL Error: Field "debugMode" is not defined by type "CreateUserInput"
GraphQL Error: Field "adminAccess" is not defined by type "CreateUserInput"

Why TypeScript Can't Save You

Compile-Time Limitations

TypeScript's type checking has limitations when it comes to spread operators and dynamic object construction:

interface UserFormData {
  name: string
  email: string
  age: number
  // TypeScript doesn't know about these at compile time:
  [key: string]: any  // Index signature allows anything
}

interface CreateUserInput {
  name: string
  email: string
  age?: number
  operation: string
}

// ❌ TypeScript allows this, but it's dangerous
const payload: CreateUserInput = {
  ...userFormData,  // May contain extra fields
  operation: 'CREATE_USER'
}
// No compile-time error, but runtime failure guaranteed

The Index Signature Problem

// ❌ Common anti-pattern that defeats TypeScript's safety
interface FormData {
  [key: string]: any  // This disables type checking
}

// ❌ Or using 'any' type
const buildPayload = (data: any) => ({
  ...data,
  timestamp: Date.now()
})

Real-World Attack Vectors

1. Debug Information Leakage

// ❌ Development debug info accidentally sent to production
const orderPayload = {
  ...orderData,
  ...debugInfo,  // Contains: userId, sessionId, internalNotes
  ...{
    // Development-only fields that shouldn't reach production
    debugTimestamp: Date.now(),
    developerNotes: 'Testing checkout flow',
    internalCustomerId: 'dev_12345'
  }
}

2. Privilege Escalation

// ❌ User input accidentally includes admin fields
const userInput = {
  name: 'John Doe',
  email: 'john@example.com',
  // Malicious user adds these fields:
  isAdmin: true,
  permissions: ['DELETE_USERS', 'ACCESS_ADMIN_PANEL'],
  role: 'SUPER_ADMIN'
}

const updateUserPayload = {
  ...userInput,  // Blindly spreads potentially malicious data
  updatedAt: new Date()
}

3. Schema Evolution Breakage

// ❌ Old code breaks when API schema changes
const legacyPayload = {
  ...oldUserData,     // Contains deprecated fields
  ...newFeatureData,  // Contains fields not yet in schema
  ...experimentalData // Contains A/B test fields
}

// API schema removed 'legacyField' and doesn't recognize 'experimentalField'
// Result: Runtime errors in production

Defensive Programming Solutions

1. Explicit Field Selection with Ramda's `pick`

import { pick } from 'ramda'

// ✅ Safe: Explicitly define allowed fields
const ALLOWED_USER_FIELDS = [
  'name',
  'email', 
  'age',
  'preferences'
] as const

const createUserPayload = {
  ...pick(ALLOWED_USER_FIELDS, userFormData),
  operation: 'CREATE_USER'
}

// Only specified fields are included, everything else is filtered out

2. Schema-Based Validation

// ✅ Define strict interfaces without index signatures
interface CreateUserInput {
  readonly name: string
  readonly email: string
  readonly age?: number
  readonly preferences?: UserPreferences
  readonly operation: 'CREATE_USER'
}

// ✅ Builder pattern for safe construction
class UserPayloadBuilder {
  private payload: Partial<CreateUserInput> = {}

  setName(name: string): this {
    this.payload.name = name
    return this
  }

  setEmail(email: string): this {
    this.payload.email = email
    return this
  }

  setAge(age: number): this {
    this.payload.age = age
    return this
  }

  build(): CreateUserInput {
    if (!this.payload.name || !this.payload.email) {
      throw new Error('Name and email are required')
    }

    return {
      name: this.payload.name,
      email: this.payload.email,
      age: this.payload.age,
      preferences: this.payload.preferences,
      operation: 'CREATE_USER'
    }
  }
}

// Usage
const payload = new UserPayloadBuilder()
  .setName(userFormData.name)
  .setEmail(userFormData.email)
  .setAge(userFormData.age)
  .build()

3. Functional Approach with Type Guards

// ✅ Type-safe field extraction
const extractUserFields = (data: unknown): CreateUserInput => {
  if (!isValidUserData(data)) {
    throw new Error('Invalid user data')
  }

  return {
    name: data.name,
    email: data.email,
    age: data.age,
    preferences: data.preferences,
    operation: 'CREATE_USER'
  }
}

// Type guard function
function isValidUserData(data: any): data is {
  name: string
  email: string
  age?: number
  preferences?: UserPreferences
} {
  return (
    typeof data === 'object' &&
    typeof data.name === 'string' &&
    typeof data.email === 'string' &&
    (data.age === undefined || typeof data.age === 'number')
  )
}

4. Whitelist-Based Object Construction

import { pick, omit } from 'ramda'

// ✅ Multiple layers of defense
const buildSafePayload = (rawData: Record<string, any>) => {
  // Layer 1: Remove known dangerous fields
  const withoutDangerousFields = omit([
    'debugInfo',
    'internalFlags', 
    'adminAccess',
    'isAdmin',
    'permissions',
    'sessionId',
    'authToken'
  ], rawData)

  // Layer 2: Only include allowed fields
  const allowedFields = pick([
    'name',
    'email',
    'age',
    'preferences'
  ], withoutDangerousFields)

  // Layer 3: Explicit construction with validation
  return {
    name: String(allowedFields.name || '').trim(),
    email: String(allowedFields.email || '').toLowerCase().trim(),
    age: typeof allowedFields.age === 'number' ? allowedFields.age : undefined,
    preferences: allowedFields.preferences || {},
    operation: 'CREATE_USER' as const
  }
}

Advanced Defensive Patterns

1. Runtime Schema Validation

Please refer to my another article
https://dev.to/marco_cheung_/client-side-graphql-variable-sanitization-preventing-runtime-errors-before-they-happen-kjn

Performance Considerations

Spread Operator Performance Impact

// ❌ Performance issues with large objects
const hugeObject = { /* 10,000 properties */ }
const anotherHugeObject = { /* 10,000 properties */ }

// Creates new object with 20,000 properties - expensive!
const combined = {
  ...hugeObject,
  ...anotherHugeObject,
  newField: 'value'
}

// ✅ Better: Only pick what you need
const optimized = {
  ...pick(['field1', 'field2', 'field3'], hugeObject),
  ...pick(['field4', 'field5'], anotherHugeObject),
  newField: 'value'
}

Memory Usage Comparison

// ❌ Memory inefficient
const createPayloads = (users: User[]) => {
  return users.map(user => ({
    ...user,           // Copies all user fields (potentially 50+ fields)
    ...user.profile,   // Copies all profile fields (potentially 30+ fields)  
    ...user.settings,  // Copies all settings (potentially 20+ fields)
    timestamp: Date.now()
  }))
}

// ✅ Memory efficient
const createOptimizedPayloads = (users: User[]) => {
  return users.map(user => ({
    id: user.id,
    name: user.name,
    email: user.email,
    avatar: user.profile?.avatar,
    theme: user.settings?.theme,
    timestamp: Date.now()
  }))
}

Testing Defensive Patterns

1. Property-Based Testing

import fc from 'fast-check'

// ✅ Test with random malicious inputs
describe('Payload sanitization', () => {
  it('should handle arbitrary malicious input', () => {
    fc.assert(
      fc.property(
        fc.record({
          // Valid fields
          name: fc.string(),
          email: fc.emailAddress(),
          // Malicious fields
          isAdmin: fc.boolean(),
          deleteAllUsers: fc.boolean(),
          __proto__: fc.anything(),
          constructor: fc.anything()
        }),
        (maliciousInput) => {
          const sanitized = buildSafePayload(maliciousInput)

          // Should only contain allowed fields
          expect(Object.keys(sanitized)).toEqual(['name', 'email', 'operation'])

          // Should not contain dangerous fields
          expect(sanitized).not.toHaveProperty('isAdmin')
          expect(sanitized).not.toHaveProperty('deleteAllUsers')
          expect(sanitized).not.toHaveProperty('__proto__')
        }
      )
    )
  })
})

2. Security-Focused Unit Tests

describe('Security tests', () => {
  it('should prevent prototype pollution', () => {
    const maliciousPayload = {
      name: 'John',
      email: 'john@example.com',
      '__proto__': { isAdmin: true },
      'constructor': { prototype: { isAdmin: true } }
    }

    const sanitized = buildSafePayload(maliciousPayload)

    expect(sanitized.isAdmin).toBeUndefined()
    expect(Object.prototype.isAdmin).toBeUndefined()
  })

  it('should handle deeply nested malicious objects', () => {
    const deepMalicious = {
      name: 'John',
      preferences: {
        theme: 'dark',
        admin: {
          deleteUsers: true,
          accessLevel: 'SUPER_ADMIN'
        }
      }
    }

    const sanitized = buildSafePayload(deepMalicious)

    expect(sanitized.preferences?.admin).toBeUndefined()
  })
})

Conclusion

The spread operator is a powerful tool, but with great power comes great responsibility. When building request payloads for APIs—especially those with strict schemas like GraphQL—defensive programming practices are essential:

Key Takeaways:

Explicit is Better Than Implicit: Use pick() or explicit field selection instead of spreading entire objects
TypeScript Isn't Enough: Runtime validation is crucial for security
Validate at Multiple Layers: Input validation, schema validation, and business logic validation
Test with Malicious Input: Use property-based testing to catch edge cases
Follow Zero Trust: Never trust input data, always validate and sanitize

The Golden Rule:

When in doubt, be explicit. It's better to write a few extra lines of code than to debug a production incident caused by unexpected fields in your API requests.

By following these defensive programming practices, you can build more robust, secure, and maintainable applications that gracefully handle the unexpected—because in software development, the unexpected is the only thing you can truly expect.

Remember: Security is not a feature you add later—it's a mindset you adopt from the beginning.

Client-Side GraphQL Variable Sanitization: Preventing Runtime Errors Before They Happen

Marco Cheung — Wed, 20 Aug 2025 16:26:05 +0000

The Problem: When Valid Code Breaks Production

Picture this scenario: You're working on an e-commerce application, and your frontend is sending a GraphQL mutation to create a product order. Everything works perfectly in development, but suddenly production starts throwing errors:

GraphQL Error: Field "debugTimestamp" is not defined by type "OrderInput"
GraphQL Error: Field "internalFlags" is not defined by type "CustomerInput"

These errors occur because your client code is sending extra fields that don't exist in your GraphQL schema. Maybe they were added during debugging, came from feature flags, or were leftover from a previous API version. Regardless of the cause, these invalid fields are breaking your production GraphQL calls.

The Solution: Client-Side Variable Sanitization

Rather than playing whack-a-mole with invalid fields, we can implement a robust client-side sanitization system that automatically removes unknown fields before sending GraphQL requests. This approach provides several key benefits:

🛡️ Reliability Benefits

Prevents Runtime Errors: Invalid fields are caught before reaching the server
Backward Compatibility: Gracefully handles API version mismatches
Debug-Safe Production: Debug fields are automatically stripped in production

🔧 Developer Experience Benefits

Automatic Cleanup: No manual field management required
Type Safety: Works seamlessly with TypeScript
Zero Configuration: Set it up once, works everywhere

Implementation Strategy

Step 1: Generate Schema Metadata with GraphQL Codegen

First, we use GraphQL Code Generator to create a runtime-accessible schema map. This gives us a lightweight, performant way to validate fields at runtime.

codegen.yml:

schema: 'https://api.example.com/graphql'
generates:
  # Generate TypeScript types
  src/types/graphql-types.ts:
    plugins:
      - typescript
      - typescript-operations
    config:
      enumsAsTypes: true
      skipTypename: true

  # Generate schema introspection for runtime validation
  src/utils/schema-metadata.json:
    plugins:
      - introspection
    config:
      minify: true

generateSchemaMap.ts:

import fs from 'fs'
import path from 'path'
import { IntrospectionSchema, IntrospectionInputObjectType } from 'graphql'

interface SchemaMap {
  [inputType: string]: {
    [fieldName: string]: string
  }
}

function generateSchemaMap(introspectionData: IntrospectionSchema): SchemaMap {
  const schemaMap: SchemaMap = {}

  introspectionData.types
    .filter((type): type is IntrospectionInputObjectType => 
      type.kind === 'INPUT_OBJECT'
    )
    .forEach((inputType) => {
      schemaMap[inputType.name] = {}
      inputType.inputFields.forEach((field) => {
        schemaMap[inputType.name][field.name] = field.type.toString()
      })
    })

  return schemaMap
}

// Generate the runtime schema map
const introspectionPath = path.join(__dirname, 'schema-metadata.json')
const introspectionData = JSON.parse(fs.readFileSync(introspectionPath, 'utf-8'))
const schemaMap = generateSchemaMap(introspectionData.data)

// Export as a TypeScript module
const outputContent = `// Auto-generated schema map for runtime validation
// Generated on: ${new Date().toISOString()}
// DO NOT EDIT MANUALLY

export const schemaMap: Record<string, Record<string, string>> = ${JSON.stringify(schemaMap, null, 2)}
`

fs.writeFileSync(path.join(__dirname, 'schemaMap.ts'), outputContent)

This generates a lightweight schema map like:

schemaMap.ts:

export const schemaMap: Record<string, Record<string, string>> = {
  "OrderInput": {
    "productId": "String!",
    "quantity": "Int!",
    "customerInfo": "CustomerInput!",
    "paymentInfo": "PaymentInput"
  },
  "CustomerInput": {
    "firstName": "String!",
    "lastName": "String!",
    "email": "String!",
    "phone": "String"
  },
  "PaymentInput": {
    "creditCardNumber": "String!",
    "expiryDate": "String!",
    "cvv": "String!",
    "billingAddress": "AddressInput"
  }
}

Step 2: Implement the Sanitization Function

Now we create a sanitization function that recursively cleans GraphQL variables:

sanitizeGraphQLVariables.ts:

import { schemaMap } from './schemaMap'

interface SanitizationOptions {
  enableLogging?: boolean
  strictMode?: boolean
}

interface SanitizationResult<T> {
  sanitizedVariables: T
  removedFields: string[]
  warnings: string[]
}

export function sanitizeGraphQLVariables<T extends Record<string, any>>(
  variables: T,
  operation: string,
  options: SanitizationOptions = {}
): SanitizationResult<T> {
  const { enableLogging = false, strictMode = false } = options
  const removedFields: string[] = []
  const warnings: string[] = []

  function sanitizeObject(
    obj: any,
    schemaTypeName: string,
    path: string = ''
  ): any {
    if (!obj || typeof obj !== 'object' || Array.isArray(obj)) {
      return obj
    }

    const schema = schemaMap[schemaTypeName]
    if (!schema) {
      if (strictMode) {
        warnings.push(`Unknown schema type: ${schemaTypeName}`)
      }
      return obj
    }

    const sanitized: any = {}

    Object.keys(obj).forEach((key) => {
      const fieldPath = path ? `${path}.${key}` : key

      if (schema[key]) {
        // Field exists in schema, process it
        const fieldType = schema[key]
        const value = obj[key]

        if (value !== null && value !== undefined) {
          // Handle nested objects
          const nestedTypeName = extractTypeName(fieldType)
          if (schemaMap[nestedTypeName]) {
            sanitized[key] = sanitizeObject(value, nestedTypeName, fieldPath)
          } else {
            sanitized[key] = value
          }
        } else {
          sanitized[key] = value
        }
      } else {
        // Field doesn't exist in schema, remove it
        removedFields.push(fieldPath)
        if (enableLogging) {
          console.warn(`Removed invalid field: ${fieldPath} from ${schemaTypeName}`)
        }
      }
    })

    return sanitized
  }

  function extractTypeName(fieldType: string): string {
    // Remove GraphQL type modifiers (!, [])
    return fieldType.replace(/[!\[\]]/g, '')
  }

  // Determine root input type from operation
  const rootTypeName = inferRootTypeName(operation)
  const sanitizedVariables = sanitizeObject(variables, rootTypeName) as T

  return {
    sanitizedVariables,
    removedFields,
    warnings
  }
}

function inferRootTypeName(operation: string): string {
  // Simple heuristic to determine input type from operation name
  if (operation.includes('createOrder')) return 'OrderInput'
  if (operation.includes('updateCustomer')) return 'CustomerInput'
  if (operation.includes('processPayment')) return 'PaymentInput'

  // Default fallback
  return 'GenericInput'
}

Step 3: Integrate with GraphQL Client

Finally, we integrate the sanitization into our GraphQL client:

graphqlClient.ts:

import { GraphQLClient } from 'graphql-request'
import { sanitizeGraphQLVariables } from './sanitizeGraphQLVariables'

interface GraphQLRequestOptions {
  enableSanitization?: boolean
  sanitizationOptions?: SanitizationOptions
}

class EnhancedGraphQLClient {
  private client: GraphQLClient
  private enableSanitization: boolean

  constructor(endpoint: string, enableSanitization: boolean = true) {
    this.client = new GraphQLClient(endpoint)
    this.enableSanitization = enableSanitization
  }

  async request<T = any>(
    query: string, 
    variables?: any,
    options: GraphQLRequestOptions = {}
  ): Promise<T> {
    let finalVariables = variables

    if (this.enableSanitization && variables) {
      const operationName = this.extractOperationName(query)
      const result = sanitizeGraphQLVariables(
        variables, 
        operationName,
        options.sanitizationOptions
      )

      finalVariables = result.sanitizedVariables

      // Log removed fields in development
      if (process.env.NODE_ENV === 'development' && result.removedFields.length > 0) {
        console.group(`🧹 GraphQL Sanitization - ${operationName}`)
        console.warn('Removed fields:', result.removedFields)
        console.warn('Original variables:', variables)
        console.warn('Sanitized variables:', finalVariables)
        console.groupEnd()
      }
    }

    return this.client.request<T>(query, finalVariables)
  }

  private extractOperationName(query: string): string {
    const match = query.match(/(?:mutation|query)\s+(\w+)/)
    return match ? match[1] : 'UnknownOperation'
  }
}

export const graphqlClient = new EnhancedGraphQLClient(
  process.env.GRAPHQL_ENDPOINT!,
  process.env.NODE_ENV === 'production' // Enable in production
)

Real-World Usage Examples

Example 1: Product Order with Debug Data

Before Sanitization:

const createOrderMutation = `
  mutation createProductOrder($input: OrderInput!) {
    createOrder(input: $input) {
      id
      orderNumber
      status
    }
  }
`

// This payload contains invalid debug fields
const variables = {
  input: {
    productId: "prod_123",
    quantity: 1,
    customerInfo: {
      firstName: "John",
      lastName: "Doe",
      email: "john@example.com",
      phone: "+1234567890",
      // ❌ Invalid fields that would break the GraphQL call
      debugUserId: "debug_123",
      internalFlags: ["testing", "debug"]
    },
    paymentInfo: {
      creditCardNumber: "4111111111111111",
      expiryDate: "12/25",
      cvv: "123",
      // ❌ Invalid field
      debugTransactionId: "debug_txn_456"
    },
    // ❌ Invalid field
    requestTimestamp: Date.now()
  }
}

// This would throw an error without sanitization
const result = await graphqlClient.request(createOrderMutation, variables)

After Sanitization:

// The sanitizer automatically removes invalid fields:
// ✅ Removed: input.customerInfo.debugUserId
// ✅ Removed: input.customerInfo.internalFlags  
// ✅ Removed: input.paymentInfo.debugTransactionId
// ✅ Removed: input.requestTimestamp

// Final sanitized payload sent to server:
{
  input: {
    productId: "prod_123",
    quantity: 1,
    customerInfo: {
      firstName: "John",
      lastName: "Doe", 
      email: "john@example.com",
      phone: "+1234567890"
    },
    paymentInfo: {
      creditCardNumber: "4111111111111111",
      expiryDate: "12/25",
      cvv: "123"
    }
  }
}

Example 2: Feature Flag Integration

// Feature-flagged fields are automatically handled
const updateCustomerMutation = `
  mutation updateCustomerProfile($input: CustomerInput!) {
    updateCustomer(input: $input) {
      id
      profile {
        firstName
        lastName
        email
      }
    }
  }
`

const variables = {
  input: {
    firstName: "Jane",
    lastName: "Smith", 
    email: "jane@example.com",
    // This field might exist in some API versions but not others
    ...(featureFlags.enableLoyaltyProgram && {
      loyaltyMemberId: "loyalty_123"
    }),
    // Debug fields that should never reach production
    ...(process.env.NODE_ENV === 'development' && {
      debugNotes: "Testing customer update",
      developerInfo: { userId: "dev_user_123" }
    })
  }
}

// Sanitization ensures only valid fields are sent
const result = await graphqlClient.request(updateCustomerMutation, variables)

Feature Flags and Environment Support

You can easily integrate sanitization with feature flags:

featureFlaggedSanitization.ts:

interface FeatureFlags {
  enableGraphQLSanitization: boolean
  strictModeValidation: boolean
  enableSanitizationLogging: boolean
}

export function createSanitizationOptions(featureFlags: FeatureFlags): SanitizationOptions {
  return {
    enableLogging: featureFlags.enableSanitizationLogging && 
                   process.env.NODE_ENV === 'development',
    strictMode: featureFlags.strictModeValidation
  }
}

// Usage in GraphQL client
const sanitizationEnabled = featureFlags.enableGraphQLSanitization
const sanitizationOptions = createSanitizationOptions(featureFlags)

const result = await graphqlClient.request(
  query, 
  variables,
  { 
    enableSanitization: sanitizationEnabled,
    sanitizationOptions 
  }
)

Testing Strategy

Unit Tests for Sanitization

describe('GraphQL Variable Sanitization', () => {
  it('should remove invalid fields from nested objects', () => {
    const input = {
      validField: 'keep me',
      invalidField: 'remove me',
      nestedObject: {
        validNested: 'keep me too',
        invalidNested: 'remove me too'
      }
    }

    const result = sanitizeGraphQLVariables(input, 'TestInput')

    expect(result.sanitizedVariables).toEqual({
      validField: 'keep me',
      nestedObject: {
        validNested: 'keep me too'
      }
    })

    expect(result.removedFields).toEqual([
      'invalidField',
      'nestedObject.invalidNested'
    ])
  })

  it('should handle arrays and null values correctly', () => {
    const input = {
      validArray: [{ validField: 'test' }],
      nullValue: null,
      undefinedValue: undefined
    }

    const result = sanitizeGraphQLVariables(input, 'TestInput')

    expect(result.sanitizedVariables.nullValue).toBeNull()
    expect(result.sanitizedVariables.undefinedValue).toBeUndefined()
  })
})

Integration Tests

describe('GraphQL Client Integration', () => {
  it('should successfully create order after sanitization', async () => {
    const dirtyVariables = {
      // Include both valid and invalid fields
      input: { ...validOrderData, ...invalidDebugFields }
    }

    // Should not throw an error despite invalid fields
    const result = await graphqlClient.request(
      CREATE_ORDER_MUTATION,
      dirtyVariables
    )

    expect(result.createOrder.id).toBeDefined()
    expect(result.createOrder.orderNumber).toBeDefined()
  })
})

Conclusion

Client-side GraphQL variable sanitization is a powerful technique that provides multiple benefits:

Prevents Runtime Errors: Eliminates GraphQL errors caused by invalid fields
Enhances Developer Experience: Automatic cleanup without manual intervention
Increases Reliability: Makes your application more resilient to API changes

By leveraging GraphQL Code Generator to create runtime schema maps and implementing a lightweight sanitization layer, you can build more robust and performant GraphQL applications.

The key to success is implementing this as an automatic, zero-configuration system that works seamlessly with your existing GraphQL client. Once set up, it provides ongoing protection against field-related errors while optimizing your network requests.

Implementation Checklist

[ ] Set up GraphQL Code Generator with introspection plugin
[ ] Generate runtime schema map from introspection data
[ ] Implement sanitization function with proper TypeScript types
[ ] Integrate with your GraphQL client
[ ] Add feature flag support for different environments
[ ] Write comprehensive unit and integration tests
[ ] Monitor performance impact and error reduction
[ ] Document the system for your team

Start with a simple implementation and gradually add more sophisticated features like strict mode validation, detailed logging, and advanced type inference. Your future self (and your production error logs) will thank you!

DEV Community: Marco Cheung

Server-Side Rendering: The Security Reality Check Every Developer Needs

The SSR Security Misconception

What SSR Actually Does for Security

✅ 1. Keeps Server Secrets Server-Side

✅ 2. Eliminates Client-Side Config Fetches

What SSR Does NOT Protect Against

❌ 1. Client-Side Data Tampering

❌ 2. Client-Side Security Logic Bypass

❌ 3. Direct API Attacks

❌ 4. Feature Flag Security Theater

Real-World Attack Examples

Example 1: E-commerce Price Manipulation

Example 2: Authentication Bypass

Example 3: Two-Factor Authentication Skip

The Correct Security Architecture

✅ Defense in Depth: Server-Side Validation

✅ Client-Side: UX Only

✅ Progressive Enhancement Pattern

Testing Your Security

Security Audit Checklist

Penetration Testing Exercise

Best Practices Summary

✅ DO:

❌ DON'T:

Conclusion

Additional Resources

Defensive Programming: The Hidden Dangers of Spread Operators in Request Payloads

The Problem: When Convenience Becomes a Security Risk

The Spread Operator Trap

What Seems Convenient...

...Can Break in Production

Why TypeScript Can't Save You

Compile-Time Limitations

The Index Signature Problem

Real-World Attack Vectors

1. Debug Information Leakage

2. Privilege Escalation

3. Schema Evolution Breakage

Defensive Programming Solutions

1. Explicit Field Selection with Ramda's pick

2. Schema-Based Validation

3. Functional Approach with Type Guards

4. Whitelist-Based Object Construction

Advanced Defensive Patterns

1. Runtime Schema Validation

Performance Considerations

Spread Operator Performance Impact

Memory Usage Comparison

Testing Defensive Patterns

1. Property-Based Testing

2. Security-Focused Unit Tests

Conclusion

Key Takeaways:

The Golden Rule:

Client-Side GraphQL Variable Sanitization: Preventing Runtime Errors Before They Happen

The Problem: When Valid Code Breaks Production

The Solution: Client-Side Variable Sanitization

🛡️ Reliability Benefits

🔧 Developer Experience Benefits

Implementation Strategy

Step 1: Generate Schema Metadata with GraphQL Codegen

Step 2: Implement the Sanitization Function

Step 3: Integrate with GraphQL Client

Real-World Usage Examples

Example 1: Product Order with Debug Data

Example 2: Feature Flag Integration

Feature Flags and Environment Support

Testing Strategy

Unit Tests for Sanitization

Integration Tests

Conclusion

Implementation Checklist

1. Explicit Field Selection with Ramda's `pick`