主题： security
-
监控所有端点（而不仅是主网站）的 TLS 证书到期情况
证书过期造成的故障，其发生时间是完全可以预知的：应从外部探测每一张实际对外提供的证书（网站、API、邮件、内部管理面板、负载均衡器）的 notAfter 日期，设置足够提前的告警时间以便手动续期，并且叶子证书和中间证书都要检查。
-
审计日志：记录什么、如何保持完整、谁可以读取
审计日志要回答的是谁在何时对哪个对象做了什么、结果如何；它由应用程序针对每一次与安全相关的操作写入，与调试日志分开保存，通过及时转移到仅追加或一次写入的存储中来防止被篡改，并且只在有记录、受限的权限下才能读取。
-
Unix file permissions and the umask
Each file has owner, group and other permission bits for read, write and execute, plus setuid, setgid and sticky bits; new files get permissions from the process umask. Secrets belong in 0600 files, directories need execute to be traversed, and services should run as a dedicated user.
-
Designing rate limits that protect the service and inform the client
Limit by the identity you can verify (account, network prefix), use atomic counters in fixed or sliding windows, answer 429 with Retry-After, keep separate budgets for reads, writes and registrations, and publish the effective limits.
-
File upload service walk-through: direct-to-storage tickets, asynchronous scanning and quotas
A design walk-through for uploads that bypass the application servers: a ticket that reserves quota and returns a signed upload URL, a completion step that verifies the stored object, a scan worker that promotes or deletes it, lifecycle rules for abandoned uploads, and a status model that explains every stored object.
-
Preventing cross-site scripting by output encoding
Escape data for the exact context it is inserted into (HTML text, attribute, JavaScript, URL, CSS), use templating that escapes by default, never build HTML by string concatenation, and back it with a strict CSP.
-
Short-link services with sequential identifiers receive more enumeration requests than services with random identifiers
Hypothesis: a URL shortener whose keys are a counter encoded in base62 lets anyone walk every link, whereas random fixed-length keys make most guesses miss; the proposal is that sequential services see a higher share of requests for existing keys from clients that never received the link, and that the share of 404 responses does not distinguish the two.
-
The Same-Origin Policy: what an origin is and what it isolates
An origin is the scheme, host and port of a URL. Script may read and modify same-origin documents, storage and responses; cross-origin reads are blocked by default, while cross-origin writes such as form submissions and embedding such as images and scripts are generally allowed. CORS relaxes reads; CSRF defences are still needed.
-
After a vulnerability report arrives: acknowledge, assess, fix in private, disclose
Once a report reaches the project's security contact, the work is a sequence with dates: acknowledge quickly, classify (working as intended, bug, feature request, vulnerability), agree an embargo with the reporter, develop the fix privately, obtain a CVE identifier, then release and publish an advisory that names affected and fixed versions and credits the reporter. The OpenSSF maintainer guide and GitHub's disclosure guidance describe this process; this article compresses it for a project with one to five maintainers.
-
Sandboxing agent actions: file system, network and credential boundaries
An agent that runs commands or code should do so inside a boundary that limits which files it can touch, which hosts it can reach and which secrets it can read; containers with dropped capabilities and a seccomp profile, user-space kernels such as gVisor, a deny-by-default network and short-lived scoped credentials are the building blocks.
-
Dependency confusion: when a public package shadows a private one
If a build resolves package names across a private index and a public one, an attacker who publishes the private name publicly with a higher version can get their code installed; pip's documentation calls --extra-index-url for private packages unsafe for exactly this reason. Defences are namespaces bound to one registry, a single proxying index, hash pinning and claiming names.
-
Loading YAML safely
Full YAML loaders can instantiate arbitrary objects from tagged nodes; always use a safe loader, pin the YAML version semantics, and validate the result against a schema before use.
-
The TLS 1.3 handshake in outline
TLS 1.3 negotiates keys in one round trip: the ClientHello already carries a key share, the ServerHello answers with its own, and everything after it, including the certificate, is encrypted. Resumption uses pre-shared keys from session tickets; 0-RTT early data is optional and replayable.
-
Validating, storing and serving user file uploads
Accept only the file types the feature needs, decide type by extension allowlist plus content check rather than the client's Content-Type, rename to a random identifier, enforce size limits before and after decompression, store outside the web root or on a separate host, and serve through a handler that sets the type, nosniff and Content-Disposition, ideally from a separate origin.
-
Red-teaming an agent workflow before it gets real permissions
Attack the agent the way content and users will: indirect prompt injection through every input it reads, tool-argument manipulation, exfiltration through tool calls and budget exhaustion; run scripted probes plus manual attempts, record what the agent did, and fix the boundary, not only the prompt.
-
Subresource integrity for third-party scripts and stylesheets
An integrity attribute on a script or link element carries a base64 SHA-256, SHA-384 or SHA-512 hash of the expected file; the browser refuses to execute or apply a resource whose content does not match. It pins exactly what a CDN may deliver, requires CORS for cross-origin files, and therefore only works for resources with fixed content.
-
Designing outgoing webhooks that receivers can trust
Sign each delivery with an HMAC over the body and a timestamp, deliver at least once with retries and idempotent event ids, keep payloads small with a link to fetch details, and let receivers verify without secrets in URLs.
-
JSON Web Tokens: what can go wrong and RFC 8725's answers
JWTs are signed claims, not encrypted secrets; validate the algorithm against an allowlist, verify issuer, audience and expiry, keep lifetimes short, never accept 'none', and remember that a stateless token cannot be revoked without a server-side list.
-
Dependency hygiene and software supply-chain checks
Know what you depend on, pin and verify it, watch for known vulnerabilities, and build from trusted sources; SLSA levels, OpenSSF Scorecard and hash-checked installs give concrete steps.
-
Security incident response for a small team: a minimum procedure
A two-person team cannot run a security operations centre, but it can prepare a contact list, a containment checklist and an evidence rule in advance; NIST SP 800-61 Rev. 3 frames incident response as part of ongoing risk management, and this procedure is the minimum that makes the first hour predictable.
机器可读： JSON