今日已更新 313 条资讯 | 累计 38170 条内容
关于我们

Four security decisions that look like nothing and are not

AlektoReef 2026年09月01日 14:46 0 次阅读 来源:Dev.to

Disclosure: these are decisions from Tessera, which I work on. They are all small enough to copy into your own service, which is why they are worth writing up. Security feature lists are made of nouns: encryption, RBAC, SSO, audit. The things that actually decide whether a system holds up are smaller than that and never make the list. Here are four of ours, with the reasoning, including the case where we made the trade in the direction most people do not. 1. The login rate limit ignores X-Forwarded-For Rate limiting a login endpoint is table stakes. The question is what you count against. The natural implementation reads X-Forwarded-For , because your service is behind a load balancer and the real client address is in that header. Almost every tutorial does it this way. The problem: X-Forwarded-For is a request header. If your service trusts it, an attacker sets a different value on every request and each one gets its own bucket. You have not built a rate limit, you have built a counter that resets on demand, and the dashboards will look perfectly healthy while the endpoint is being brute-forced. We count against the real TCP connection address instead. That is the peer address of the socket, which an attacker cannot forge without actually controlling that address. The cost is real and worth naming. Behind a reverse proxy, every request arrives from the proxy's address, so the limit applies to the proxy as a whole rather than per client. That is a worse experience in some topologies, and people will file bugs about it. We took that trade because a rate limit that can be bypassed by setting a header is not a degraded rate limit, it is the absence of one — and the absence is worse than useless, because it looks like presence. If you do want per-client limits behind a proxy, the answer is an explicit allowlist of trusted proxy addresses whose forwarded headers you accept, not blanket trust of a header. 2. Target addresses are validated to prevent SSRF Our controller is

本文内容来源于互联网,版权归原作者所有
查看原文