API security tends to get attention after an incident, not before one — which is backwards, because the basics below are neither expensive nor complicated to implement from the start.
Authenticate every request, no exceptions
An internal-only endpoint that “doesn’t really need” authentication because only your own front end calls it is one configuration change away from being exposed. Every endpoint should authenticate, even ones that currently feel safe by obscurity.
Rate limiting, applied deliberately
Without it, a single misbehaving client — or an actual attack — can degrade the API for everyone. Rate limits don’t need to be aggressive to be useful; they just need to exist, tuned to realistic usage patterns.
Validate input as if it’s hostile, because eventually it will be
Trusting that a request will always be well-formed because your own front end always sends it that way ignores every other way a request can reach the endpoint — a different client, a bug, or someone testing your API directly.
Least-privilege tokens
A token or API key that grants full access when the integration only needs to read one resource is a bigger blast radius than necessary if that credential is ever leaked. Scoped permissions limit the damage of a single compromised credential.
Log enough to investigate, not so much you can’t find anything
When something does go wrong, the difference between a quick investigation and a multi-day forensic exercise is usually whether sensible logging was already in place before the incident, not added afterward in a panic.