Rules Hub
Coding Rules Library
Rule priority, scope & exceptions
Use this to align rules with the senior-level structure (P0/P1/P2, scope, exceptions/tradeoffs).
Never put secrets or tokens in a URL query string
Send auth tokens as headers, never as query-string parameters.
Bad example
| 1 | const url = `${baseUrl}/users.json?auth_token=${encodeURIComponent(token)}&limit=${limit}`; |
| 2 | await fetch(url); |
Explanation (EN)
URLs are routinely written to access logs, proxy logs, browser history, and error-tracking breadcrumbs in full — putting a token there leaks it into every one of those places, and hand-typed re-runs of the command end up pasted into chat or terminals other people can see.
Objašnjenje (HR)
URL-ovi se rutinski u cijelosti zapisuju u access logove, proxy logove, povijest preglednika i error-tracking tragove — stavljanjem tokena tamo curi u svako od tih mjesta, a ručno ponovno pokretanje naredbe završi zalijepljeno u chat ili terminal koji drugi mogu vidjeti.
Good example
| 1 | const url = `${baseUrl}/users.json?limit=${limit}`; |
| 2 | await fetch(url, { headers: { Authorization: `Bearer ${token}` } }); |
Explanation (EN)
Pass the token as an Authorization header so it never appears in the request line that gets logged. If the third-party API genuinely only accepts the token as a query parameter, say so explicitly in a comment so the tradeoff is visible on review rather than looking like an oversight.
Objašnjenje (HR)
Proslijedi token kao Authorization header kako se nikad ne bi pojavio u liniji zahtjeva koja se logira. Ako vanjski API stvarno prihvaća token samo kao query parametar, to izričito navedi u komentaru kako bi kompromis bio vidljiv pri reviewu, a ne izgledao kao previd.