Spotuify Security Audit Synthesis

The 2026-05-27 spotuify security audit turned "is this safe to publish?" into three concrete standards: secure defaults, explainable exceptions, and continuous evidence.

The core insight

spotuify is not a hosted web app. Its risky edges are local-first edges:

• a long-lived daemon,
• local IPC,
• Spotify bearer material,
• OS credential storage,
• release binaries,
• docs site distribution,
• user-triggered mutations against a real Spotify account.

That means the audit cannot stop at "Rust is memory safe" or "the tests pass." The product has to look non-malicious to a distribution site and behave non-surprisingly on a user's machine.

What changed

• Secrets now require explicit reveal intent: auth bearer --reveal-secret and config get client_secret --reveal-secret.
• Config files are written 0600 on Unix.
• OAuth redirect binding rejects non-loopback hosts.
• Cover-art downloads have a body-size limit before decode.
• The Vercel site has security headers and no hand-written inline font onload.
• Site dependencies are audited in CI and covered by Dependabot.
• Rust advisories are checked in CI with explicit cargo-deny exceptions for known transitive upstream gaps.
• Release archives get GitHub artifact provenance attestations alongside checksums.
• A SECURITY.md gives reporters a private, low-leakage path.
• The auth revocation loop got turned into a token-store rule: refresh tokens are shared mutable state, so refresh and purge need a cross-process lock, persisted-token reload, and compare-before-delete. See Refresh Token Rotation Is Shared State.

The accepted risk

Two Rust advisories remain transitive:

• rsa through librespot-core.
• instant through tantivy -> measure_time.

The important change is not that these disappeared. They did not. The important change is that they are now visible, named, and reviewed by CI instead of hiding in a one-off local audit.

The durable lesson

Security work becomes maintainable when it is made ordinary:

• a rubric in the repo,
• tests for each sharp edge,
• CI gates for dependency drift,
• docs that tell users when a release is unsigned or when a command reveals a secret,
• small explicit exceptions where upstream owns the fix.
• auth state treated as operational state, not just "secrets in a keychain."

That is the difference between a panic before distribution and a project that can survive distribution audits repeatedly.

See also

• Security Audit Rubric
• Secure by Default
• Rust Security Posture