Security

Introduction

SOASAP applications authenticate using SDK API keys. Those credentials determine project access, environment access, configuration synchronization, and SDK identity.

The security of a SOASAP deployment depends on:

• protecting API keys
• isolating environments
• secure deployment pipelines
• controlled key rotation
• secure application configuration
• operational monitoring

Security model

Authentication occurs during synchronization. Runtime flag evaluation happens locally. Application requests do not authenticate with SOASAP Cloud on every evaluation.

Compromising an API key affects synchronization. It does not automatically compromise already running applications that continue evaluating from previously synchronized snapshots. See Offline Operation and Outages.

API key responsibilities

API keys:

• authenticate SDK clients
• identify project and environment
• authorize configuration synchronization
• establish SDK identity

API keys are not:

• user authentication tokens
• end-user identities
• application session credentials
• authorization rules
• encryption keys
• database passwords

Environment isolation

Each environment should have its own API key.

Never reuse one key across environments. Isolation limits blast radius, simplifies rotation, prevents accidental production access, separates operational ownership, and simplifies auditing.

Project isolation

Separate projects should use separate credentials. Avoid sharing one credential across unrelated products, services, business units, customers, or experimental deployments.

Credential boundaries should match operational ownership.

Least privilege

Applications should receive only the credentials required for their role.

Avoid:

• sharing one credential everywhere
• using production credentials in test environments
• distributing keys unnecessarily
• copying production secrets into developer machines

Least privilege reduces operational impact during incidents.

Storing API keys

Store keys using:

• environment variables
• cloud secret managers
• platform secret stores
• Kubernetes Secrets
• managed deployment secrets

Avoid:

• source control
• Git repositories
• documentation examples
• screenshots
• public issue trackers
• CI logs
• shell history where possible
• shared documents

Keys should enter the application through deployment configuration rather than source code.

Server applications

Server-side SDKs should normally receive API keys from secure deployment configuration. Typical sources include environment variables, container secrets, VM configuration, and secret managers.

Do not hardcode production credentials.

Web applications

Anything shipped to a browser can potentially be inspected, including JavaScript bundles, browser developer tools, source maps, network inspection, and cached assets.

Recommend:

• prefer server-side evaluation when possible
• if browser SDKs are used, use credentials specifically intended for public-client use
• never expose server-only credentials to browsers

Do not assume a client-visible key is secret because it is minified or obfuscated.

Mobile applications

Applications distributed through app stores cannot fully hide embedded credentials. APK inspection, IPA extraction, reverse engineering, and rooted or jailbroken devices can expose values packaged with the binary.

Recommend:

• avoid embedding privileged production credentials
• use client-scoped keys when supported
• prefer server-side evaluation for highly sensitive decisions
• assume distributed binaries can be analyzed

Client-side security model

Feature flags are configuration. They are not an authorization mechanism.

Do not rely on feature flags alone to:

• enforce payments
• protect premium features
• authorize administrative operations
• enforce permissions
• validate identities

Server-side authorization must remain authoritative. See Production Safety.

Secret managers

Common approaches include AWS Secrets Manager, Azure Key Vault, Google Secret Manager, HashiCorp Vault, and Kubernetes Secrets. The exact solution depends on the deployment platform.

SOASAP does not require a specific secret manager. Use existing organizational secret infrastructure.

Environment variables

Prefer a dedicated configuration name such as SOASAP_SDK_KEY rather than hardcoded literals.

Account for:

• deployment injection
• runtime configuration
• container configuration
• local development overrides
• secret masking

Do not print environment variables containing credentials into logs.

Container security

Containers should receive secrets at runtime. Avoid baking credentials into images, committing .env files, or storing secrets inside immutable images.

Kubernetes

Store credentials in Kubernetes Secrets or an approved external secret system. Consider namespace isolation, RBAC, service accounts, workload identity, and mounted secrets versus environment variables.

Separate Secrets for Development, Staging, and Production. Keep Production credentials out of non-production namespaces.

CI/CD security

Deployment pipelines should protect SDK credentials.

Avoid:

• plaintext pipeline variables
• credentials inside build artifacts
• logging secrets
• exposing secrets in pull requests

Recommend:

• masked secrets
• deployment-time injection
• environment-specific variables
• approval workflows for production

Logging

Never log:

• API keys
• Authorization headers
• full connection URLs containing secrets
• secret configuration dumps

Safe logging includes:

• environment
• synchronization status
• project identifier where appropriate
• connection state
• error codes

Redact sensitive values before they reach log aggregators, crash reports, or support tickets.

Monitoring

Monitor:

• authentication failures
• invalid API keys
• revoked keys
• repeated authorization failures
• synchronization failures
• unusual reconnect patterns
• deployment using incorrect environment
• unexpected production traffic from development deployments

See Invalid API Key for credential troubleshooting.

Key rotation

Rotate keys when credentials may have been exposed, when staff access changes, on a regular schedule required by policy, or when moving ownership between teams.

In SOASAP, rotating an environment key regenerates it and permanently invalidates the previous value. Prepare all consuming deployments, regenerate, deploy the new key quickly, then verify synchronization across the fleet. Operational steps: API Keys.

Compromised key response

1. Confirm compromise.
2. Identify affected environment.
3. Create replacement key.
4. Deploy replacement.
5. Verify synchronization.
6. Revoke compromised key.
7. Audit deployments.
8. Review logs.
9. Document incident.

Prioritize Production credentials. Treat any key that appeared in Git, CI logs, screenshots, or public packages as compromised until proven otherwise.

Key revocation

Revoking a key prevents future authenticated synchronization.

• Running SDKs — continue evaluating existing snapshots
• New synchronization — fails until a valid key is configured

This behavior protects runtime availability while still enforcing authentication for future configuration delivery. After revocation, plan cache and restart behavior carefully — see Cache Strategy and Persistent Cache.

Development vs production

Never deploy development credentials into production.

Multi-team organizations

Different teams should not automatically share production credentials. Recommend project ownership, environment ownership, documented responsibility, and controlled access.

Align credential distribution with who can change configuration and who can deploy the consuming services.

Third-party access

Do not share production SDK keys with vendors, consultants, temporary contractors, or support tools. Use controlled operational processes instead — temporary scoped access, supervised changes, or non-production environments when external help is required.

Backups

Do not store API keys inside backup archives unnecessarily. Review exported configuration, deployment artifacts, VM snapshots, and container images for embedded credentials.

Local SOASAP cache files are configuration state, not a secret store, but they still belong in access-controlled application data directories. See Cache Strategy.

Common misconfigurations

Production key committed to Git

Expands exposure to anyone with repository access, clones, forks, and CI checkout history. Rotate immediately and purge from history where policy requires it.

Same key across every environment

Turns a Development leak or misconfiguration into a Production incident and complicates rotation and auditing.

Secret printed in logs

Places credentials into log stores, SIEM exports, support tickets, and developer machines with log access.

Public JavaScript bundle containing privileged key

Makes a server-grade credential inspectable by any browser user. Prefer server-side evaluation or client-scoped credentials.

Shared credential across unrelated services

Increases blast radius and makes ownership and revocation ambiguous during incidents.

Forgotten key rotation

Leaves long-lived credentials in circulation after staff changes, vendor access, or prior exposures.

Hardcoded credentials

Couples secret lifecycle to code releases and increases the chance of accidental disclosure.

Screenshot containing secrets

Spreads credentials through chat, tickets, and documentation systems that are rarely treated as secret stores.

Security checklist

Incident response checklist

Copy the following into an internal runbook and fill it during a credential incident.

Incident:
Affected Key:
Environment:
Replacement Created:
Deployment Updated:
Old Key Revoked:
Synchronization Verified:
Logs Reviewed:
Retrospective Completed:

Common misconceptions

"Feature flags provide authorization."

False. Authorization belongs to application security.

"API keys may safely be committed if the repository is private."

False. Private repositories still expand exposure to clones, CI, forks, and broader organizational access.

"Production and Development can safely share credentials."

False. Environment isolation is a fundamental security practice.

"Rotating a key requires application downtime."

False. Application evaluation can continue from local snapshots; plan a coordinated regenerate-and-redeploy so synchronization recovers quickly.

"If an API key is revoked, running applications immediately stop evaluating flags."

False. Existing snapshots continue until reauthentication becomes necessary for new synchronization.

"Embedding a key inside a mobile app makes it secret."

False. Distributed binaries should be assumed inspectable.

Relationship to other SOASAP concepts

Related documentation

• API Keys — issuing, rotating, and revoking environment-scoped SDK keys
• Production Safety — kill switches, defaults, and safe rollout practices
• High Availability — evaluation independence during sync disruption
• Outages — incident behavior when sync or credentials fail
• Cache Strategy — local snapshot storage and environment isolation
• Offline Operation — evaluation while synchronization is unavailable
• Persistent Cache — snapshot restoration across restarts
• Invalid API Key — diagnosing authentication and credential failures
• Authentication — API authentication model
• SDK Documentation — platform-specific configuration and key injection