A developer platform's API is used by thousands of external integrators. What security properties must be defaults rather than options?

Why defaults matter more than features

Integrators use defaults. A security capability that must be configured is used by a minority, and the majority's configuration is whatever the quickstart showed. The security posture of the ecosystem is therefore the posture of the default path, not of the most secure available path.

What must be default

• Least-privilege scopes, with credentials created narrow and widened deliberately. A key that can do everything because that was the simplest thing to issue is the most common cause of an over-privileged leak.
• Short-lived credentials with refresh, rather than permanent keys. Permanent keys end up in repositories, and the expiry is what bounds the damage.
• Rate limits applied from the first request, so an abusive or buggy integration is contained before it is noticed.
• Signed webhooks, with verification documented as required rather than optional — an unverified webhook endpoint is an unauthenticated write API.
• Idempotency on mutating operations, which is a correctness property with a security consequence: retries during an attack should not multiply effects.
• Audit logging visible to the customer, so they can detect misuse of their own credentials without asking you.

What must be easy rather than merely possible

• Rotating a credential without downtime, which requires supporting two valid credentials simultaneously. If rotation causes an outage, customers will not rotate.
• Scoping a credential to an environment or an IP range, in the interface where keys are created rather than in an advanced settings page.
• Revoking a specific credential without affecting others, which requires per-credential identity rather than a shared account secret.

The detection obligation

Leaked credentials are inevitable at scale. The platform should scan public repositories for its own key format, revoke automatically on detection, and notify — because the interval between a key appearing publicly and being exploited is measured in minutes, and a support ticket is far too slow.

That requires the key format to be recognisable, which is a small design decision with a large operational payoff and is easy to get wrong by using an opaque random string indistinguishable from any other.