Principle 1: tokens are credentials, not configuration
A common mistake: treating VOMO tokens like ordinary configuration values — environment variables, config files, deployment manifests. They’re not. They’re secrets that should be handled with the same care as database passwords or API keys.What this means in practice
The “secrets in env vars” trap
It’s tempting to dismiss the env-var concern — “we control the production environment, only admins can see env vars.” But:- Container orchestrators often dump env vars in logs during debugging
- Crash reports may include process memory
- Sidecar containers and observability tools sometimes capture env state
- A developer with prod access becomes a single point of compromise
Principle 2: defense in depth — multiple layers
No single layer of protection is enough. Layer them: Each layer is independent. If one fails (e.g., a misconfigured IAM rule), the others provide backstops (the secrets manager logs the unusual access; rotation limits how long the exposure lasts).Layer by layer
Principle 3: per-customer credential isolation
For multi-tenant partner integrations, each customer’s token must be isolated from other customers’ tokens. A bug or compromise affecting one customer’s credentials shouldn’t cascade.Storage pattern
JavaScript
Why “every access requires a reason”
Forcing areason parameter is a code-organization tactic: it makes it visible in code review when token access is happening. A grep for getToken( shows every site that pulls a token; the reason string explains why.
Common reasons:
'polling_cycle''manual_backfill''reconciliation''customer_dashboard''health_check'
Principle 4: minimize token exposure in memory
Once decrypted, the token lives in memory. Minimize how long and where:Pattern: short-lived decrypted handles
JavaScript
Don’t put tokens in long-lived caches
A common anti-pattern: caching decrypted tokens for performance. This trades a tiny performance benefit for substantial security risk.JavaScript
Principle 5: scope minimization
Customers issue tokens via the VOMO admin portal. The token grants access to the customer’s organization — there’s no fine-grained scoping by resource type in the API itself. But the partner integration can choose to use the token more or less broadly. Principle: use the token for the narrowest set of operations needed for the workflow.Pattern: per-workflow token use
JavaScript
usersToken and writeToken are the same token (VOMO doesn’t issue separate read/write tokens), the audit log separates the two uses. If a compromise is detected, the log shows whether the integration was reading or writing at the moment.
Future-proofing for finer-grained scoping
If VOMO ever introduces fine-grained scopes, integrations that have been careful about declaring operation intent will be ready. Integrations that treat the token monolithically will need refactoring.Principle 6: customer-side handoff is the weak link
The path from customer → partner is where most token compromises happen:Pattern: secure-form-based handoff
The right pattern: customer-facing form on the partner’s web UI, TLS-encrypted, that captures the token and immediately encrypts it for storage:JavaScript
Customer-side guidance to include in onboarding
Document for the customer:- The token grants full access to their VOMO data — treat it like a password
- Don’t share via email, chat, or unencrypted channels
- The form-based handoff is the only secure path
- After submission, the partner stores it encrypted
- Notify the partner immediately if the customer suspects the token was exposed
- Use the customer’s VOMO admin portal to revoke/rotate the token
Principle 7: rotation
Even with perfect storage, tokens should rotate periodically. Rotation:- Limits the exposure window if a token is leaked
- Forces audit of which integrations are actually using which tokens
- Aligns with security best practices for compliance audits
Rotation patterns
Customer-initiated rotation: The customer generates a new token in the VOMO admin portal; updates the partner integration; the old token is revoked. The integration uses the new token for verification (test query); only after verification does it commit to the new token; then the customer revokes the old. Scheduled rotation reminder: Partner sends customers an email every N months reminding them to rotate.JavaScript
Principle 8: audit everything
Comprehensive audit logging is a security primitive. Every meaningful event should be logged:Audit log integrity
The audit log itself can be a target — an attacker may try to delete or modify entries to cover tracks. Mitigations:- Append-only design (no UPDATE or DELETE statements supported)
- Separate access control — the application can write but only ops can read
- Off-system replication — entries also sent to a separate log aggregation system
- Tamper-evident chaining — each entry includes a hash of the previous (blockchain-style)
Retention
How long to keep audit logs:
Longer retention provides better forensics but costs more storage. Tier by importance.
Principle 9: secure handling of PII
Volunteer data is PII (personally identifiable information). Names, emails, phone numbers, addresses, birthdays — all of it is regulated under various privacy laws (GDPR in EU, CCPA in California, etc.).Practices that matter
The data minimization pattern
For partner integrations, don’t store PII you don’t need. If you only need to know “Bruce participated in 5 projects last month,” you don’t need to store his birthday, gender, address. Trimming the data you persist limits exposure:JavaScript
Customer-initiated deletion
For GDPR Article 17 (right to erasure) compliance, support customer-initiated deletion of specific persons:JavaScript
Principle 10: customer offboarding
When a customer cancels the integration, secure handling of their credentials and data is essential.Offboarding checklist
JavaScript
Why a retention period
Customers sometimes cancel and then re-enable (changed their mind, business needs evolved). A retention period (30-90 days) lets them resume without full re-onboarding. But: communicate the retention period clearly during offboarding, including the final-deletion date. For privacy-sensitive customers, offer immediate deletion as an opt-in.Principle 11: respond to compromise quickly
When you suspect a credential has been compromised — leaked in a log, exposed in a code review, accessed without authorization — the response should be immediate:Incident response sequence
Speed matters
The window between detection and containment is the highest-risk period. Build tooling that makes containment fast:JavaScript
Security review checklist
Periodically (quarterly is reasonable), walk through this checklist:- All tokens are stored encrypted at rest
- All tokens are in a secrets manager, not application code or config
- Token access is logged with reason in every code path
- No tokens appear in logs, error traces, or monitoring dashboards
- Per-customer encryption keys are used (not just a single master key)
- Token rotation reminders are sent every 6 months
- HTTPS-only enforced (no HTTP fallback)
- PII storage minimized to what workflows actually use
- Customer-initiated data deletion is supported and tested
- Offboarding deletes credentials immediately; data on a documented retention
- Audit logs cannot be modified or deleted by application code
- Incident response runbook exists and has been rehearsed
- Compliance requirements (GDPR, CCPA, etc.) are documented and met
Where to go next
Versioning and Backward Compatibility
The patterns for surviving API changes without breaking integrations.
Sync Architecture Patterns
The architectural patterns this security model fits into.
Build a Volunteer Self-Service Portal
The recipe that puts these security patterns to work in a customer-facing product.
Authentication
The reference page for VOMO’s auth model.