The visible problem may look like one API or tuning value, but reliability is decided by state ownership, resource bounds, and recovery after failure. A public-looking URL is not a safe destination: DNS can rebind, redirects can enter private networks, and alternate IP forms encode local addresses.
Security review starts with assets, attacker capability, and trust boundaries, then reauthorizes every state transition. Validation, rate limits, and audit complement rather than replace authorization.
Make the implementation decisions explicit
List non-negotiable invariants before selecting performance knobs. Tuning can roll out gradually; identity, permission, and terminal-state rules cannot drift at runtime.
- Allow only HTTPS, normalize hostnames, resolve all A and AAAA records, reject loopback, link-local, private, and metadata ranges, and revalidate every redirect through controlled egress.
- Separate protocol facts, user intent, and automatic recovery; automation may restore facts but never overturn an explicit choice.
- Retries need an idempotency key, backoff, and deadline; after the deadline create a new task instead of reviving old callbacks.
The delivery standard for SSRF Defense Validates Resolved Destinations, Not URL Appearance is a usable normal path, convergent failures, bounded resources, and a state users can understand. The result is a production capability that can be explained, degraded safely, and rolled back—not a demo that works once.
Failure paths that are easy to miss
Failure and success must share one state model. An error toast that neither releases resources nor propagates a terminal state leaves dirty work for the next recovery attempt.
- Validating one resolution then letting the client resolve again leaves DNS rebinding, while blocking only 127.0.0.1 misses IPv6, integer forms, and private ranges.
- Fixing only the UI leaves queues, locks, or expired credentials for the next operation to inherit and fail again.
- Ideal-size tests miss large files, long sessions, and concurrency that cross hidden limits and cause cascading failure.
How to verify it before release
Do not stop verification when the final action succeeds. Count side effects, measure wait time, inspect privacy, and prove the next run begins from a clean baseline.
- Test rebinding domains, mixed public/private answers, redirect chains, IPv6-mapped forms, and huge slow responses; every unsafe path must fail within budget.
- Race refresh, cancel, timeout, and remote completion in one scheduling window; assert one terminal state and one side effect.
- Allowlist log and analytics fields, proving payloads, secrets, full IP addresses, and identifying data never leave the device.
A capability becomes maintainable when it degrades safely, repetition adds no side effects, and its signals reveal a fault before user reports do.