Security Best Practices changeddocs/2026-07-28/tutorials/security/security_best_practices
Upstream edited this page at 28 Jul 2026 16:18 UTC, give or take a minute or two: the time comes from Anthropic’s own sitemap rather than from a commit. This site recorded the change at 20 Oct 2026 20:07 UTC.
Upstream edited
Recorded here
Lines+26added
Lines−26removed
From line
442
where the diff opens
First seen
14 Aug 2026
this site's first read of the page
Recorded edits2to this page, all time
The whole hunk
from line 442, old and new numbered
/
from line 442
442442* Link-local: `169.254.0.0/16` (including cloud metadata endpoints)
443443* Private IPv6 ranges: `fc00::/7`, `fe80::/10`
444444
445<Note>
446 Avoid implementing IP validation manually. Attackers exploit encoding tricks
447 (octal, hex, IPv4-mapped IPv6) that custom parsers often miss.
448</Note>
445> [!NOTE]
446>
447> Avoid implementing IP validation manually. Attackers exploit encoding tricks
448> (octal, hex, IPv4-mapped IPv6) that custom parsers often miss.
449449
450450**Validate Redirect Targets**
451451
from line 946
946946process, minimizing user friction while following the principle of
947947least privilege.
948948
949<Note>
950 Scope accumulation across operations is a client-side responsibility. Clients
951 **SHOULD** compute the union of previously requested scopes and newly
952 challenged scopes when initiating re-authorization, as described in [Step-Up
953 Authorization
954 Flow](/specification/2026-07-28/basic/authorization#step-up-authorization-flow).
955 This allows servers to remain stateless with respect to client scope sets
956 while ensuring clients do not lose previously granted permissions.
957</Note>
949> [!NOTE]
950>
951> Scope accumulation across operations is a client-side responsibility. Clients
952> **SHOULD** compute the union of previously requested scopes and newly
953> challenged scopes when initiating re-authorization, as described in [Step-Up
954> Authorization
955> Flow](/specification/2026-07-28/basic/authorization#step-up-authorization-flow).
956> This allows servers to remain stateless with respect to client scope sets
957> while ensuring clients do not lose previously granted permissions.
958958
959<Note>
960 **Hierarchical scopes**: Some authorization servers define scope hierarchies
961 where a broader scope implies narrower ones (for example, an `admin` scope
962 that subsumes `read`). When accumulating scopes, the client's union may
963 contain semantically redundant entries. For example, a token previously
964 granted a broad scope may be challenged with a narrower one it already
965 implies. Clients need not deduplicate hierarchically; authorization servers
966 typically normalize such redundancy during token issuance. Servers, for their
967 part, must account for hierarchy when deciding whether a token is sufficient
968 for an operation, but this does not affect the scopes they emit in a
969 challenge.
970</Note>
959> [!NOTE]
960>
961> **Hierarchical scopes**: Some authorization servers define scope hierarchies
962> where a broader scope implies narrower ones (for example, an `admin` scope
963> that subsumes `read`). When accumulating scopes, the client's union may
964> contain semantically redundant entries. For example, a token previously
965> granted a broad scope may be challenged with a narrower one it already
966> implies. Clients need not deduplicate hierarchically; authorization servers
967> typically normalize such redundancy during token issuance. Servers, for their
968> part, must account for hierarchy when deciding whether a token is sufficient
969> for an operation, but this does not affect the scopes they emit in a
970> challenge.
971971
972972#### Common Mistakes
973973
No line in this hunk matches that.