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
| Anti-pattern | Why it’s wrong | Better |
|---|---|---|
| Token in environment variable on production | Anyone with deploy access sees them | Secrets manager with audit logging |
| Token in config file checked into git | Permanent leak in source history | .gitignore + secrets manager |
| Token in CI/CD logs | Logs are often broadly accessible | Mask in logs; never echo |
| Token sent in customer support email | Email is not a secure channel | Secure customer portal upload |
| Token in screenshots / docs | Permanent visual leak | Redact in any visual capture |
| Same token across multiple environments (dev/prod) | A dev leak compromises production | Separate tokens per environment |
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
| Layer | Purpose |
|---|---|
| Encryption at rest | Tokens encrypted in the database; only decrypted in memory when needed |
| Secrets manager | Tokens stored in a purpose-built service (not your application DB) |
| Access control | Only specific service accounts can read decrypted tokens |
| Audit logging | Every access to a token is logged with who, when, why |
| Rotation | Tokens rotated on a schedule; old tokens expire |
| Egress restrictions | Network policies prevent token from leaving the system in unexpected ways |
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:| Handoff method | Risk |
|---|---|
| Customer pastes token into a partner web form | Token transits over TLS; partner stores it |
| Customer emails token to partner support | Email is not encrypted; recipients vary |
| Customer texts/IMs token | Messaging is often archived; clients are diverse |
| Customer types token into a screen-shared session | Visible in screen recording |
| Customer commits token to a shared git repo | Catastrophic — appears in history |
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:| Event | What to log |
|---|---|
| Token storage | customer_id, actor, timestamp; not the token itself |
| Token access | customer_id, actor, reason, timestamp |
| Token rotation | customer_id, actor, timestamp; old and new fingerprints (not full tokens) |
| Failed authentication (401 from VOMO) | customer_id, request context, timestamp |
| Customer onboarding | customer_id, who initiated, configuration set |
| Customer offboarding | customer_id, what data was deleted/retained |
| Data access patterns (per-record) | customer_id, resource type, ID, operation, trace ID |
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:| Audit type | Retention |
|---|---|
| Security events (auth failures, rotations) | At least 1 year |
| Operational events (polling, processing) | 30-90 days |
| Per-record access logs | 30-90 days |
| Customer onboarding/offboarding | Permanent (or per legal requirement) |
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
| Practice | What it does |
|---|---|
| Encryption in transit (HTTPS only) | Prevents network interception |
| Encryption at rest | Protects against database breaches |
| Minimum data retention | Reduces blast radius |
| Per-customer data isolation | Prevents cross-customer leaks |
| Customer-initiated data deletion | Complies with right-to-be-forgotten requests |
| Access logging | Enables audit of who saw what |
| Secure deletion | Ensures deleted means deleted (not just marked) |
| Subprocessor disclosure | Document what third-party services see customer data |
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
| Step | Action |
|---|---|
| Detect | Alert fires, audit log review surfaces concern, customer reports issue |
| Contain | Immediately disable the affected customer’s integration; revoke their token via VOMO admin if possible |
| Investigate | What was accessed? What was the scope? When did it start? |
| Notify | Customer first (always), then internal stakeholders, then any regulatory bodies if required |
| Recover | Customer issues new token; partner stores; integration resumes |
| Document | What happened, what was the impact, what’s being done to prevent recurrence |
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.