Security Guides
Passwords, MFA, devices, public Wi-Fi, servers, dependencies, Git, exposed environments — practical, goal-oriented guides to defenses you can apply today.
Public buckets — "block public access is on" does not mean the hole is gone
Bucket leaks come from configuration, not attack. The line that matters in the docs: block public access settings do not alter existing policies or ACLs — the block covers the hole, it does not close it, and removing it restores public access. So the goal is not "blocking is enabled" but "nothing is public even with blocking off". Apply it at the account level, because a bucket policy can grant someone the ability to turn a bucket-level block off. And "public" is defined more broadly than people assume.
Common security mistakes are failures of assumption, not of skill — four beliefs that keep breaking
Incidents come from a small set of recurring shapes, and the shapes are clearer sorted by belief than by technology. Four of them: defaults must be safe (nothing was configured), unused things must be harmless (nothing was closed), we would notice (nothing is observable), and validated input must be safe (too much was delegated to the input). None of these needs deep technical knowledge to fix — they need a habit of checking. Here is what to look at for each.
Insecure deserialization — the danger is not the data, it is letting the data choose the type
The danger in deserialization is not that bad values arrive; it is that some formats let external data decide which type of object to construct. So the damage does not stop at corrupted data — OWASP lists denial of service, access control bypass and remote code execution. Two defenses: switch to a pure data format so nothing chooses types for you, and sign serialized messages so unsigned ones are never restored. And some mechanisms cannot be made safe by configuration at all; the only fix is not using them.
Password reset design flaws — harden login all you like, this is the way in
A reset flow is a mechanism for letting someone who does not know the password set a new one — which makes it an authentication path in its own right. Harden the login all you like: if reset is weak, reset is your real authentication strength. Five failure shapes: guessable tokens, tokens that never expire, links that live on in a mailbox, links whose destination can be set from outside (Host header), and responses that reveal whether an account exists. The craft is separating what the guidance requires from the numbers it leaves to you.
Prototype pollution in Node.js — where the runtime says "not our vulnerability", nobody else is standing
Prototype pollution is what happens when a special key in external input reaches JavaScript's built-in prototypes, usually through a recursive merge. Two outcomes: properties you never set appear everywhere (breaking authorization and option checks), or built-in methods vanish and the app crashes somewhere unrelated. The part that matters most is ownership — Node.js states this is not a vulnerability in Node.js core, and that defenses belong at the application and dependency level. Waiting for a fix is not a strategy here.
Rate limiting and abuse control — counting requests stops neither brute force nor a runaway bill
Rate limiting usually fails not because the limit was too loose but because the wrong question was asked. Three questions: who you count (IP can be forged and is shared by real users, so identity comes first), what you count (requests alone miss expensive single operations — cost, size, record counts), and what happens at the ceiling (blunt lockout is a denial of service against legitimate users). NIST caps consecutive failures at 100 and asks for delays and CAPTCHA instead of shutting people out; OWASP includes third-party spending limits, the last line for financial damage.
Security headers are not a list to stack — what still works, what is obsolete, and what now does harm
More headers is not better. Sort them into three groups: still effective (CSP, HSTS, X-Frame-Options, nosniff, Referrer-Policy, Permissions-Policy), obsolete (Expect-CT has been mostly obsolete since June 2021), and actively harmful (MDN marks X-XSS-Protection deprecated and non-standard and warns it can create XSS vulnerabilities in otherwise safe sites). Copy a stale list and you import the harmful settings along with the good ones.
Subdomain takeover (dangling DNS) — your domain is served by an attacker, and your servers were never touched
Delete a cloud resource without deleting the DNS record and you have a dangling entry: anyone can claim that subdomain by provisioning a resource with the same FQDN. Your servers stay untouched while a legitimate subdomain serves an attacker's content. The damage is not cosmetic — apps commonly expose session cookies to wildcard subdomains, so the hijacked one can read them. And the documentation explicitly rejects the belief that a certificate protects you. The fix is making deletion order a mechanism, not a memory.
In 2026 the Breaches Came Through Valid Credentials, Not Vulnerabilities — A Cross-Case Read
Classified by entry path, the major Japanese incidents disclosed in August 2026 skew toward credential-led intrusion rather than exploited vulnerabilities. The shared trait: the victim's own servers were untouched and the way in was a legitimate door somewhere outside them. This site's conclusion — flawless vulnerability management stops none of this, so the centre of gravity has to move toward credential lifetime and scope, and an inventory of the vendors and SaaS that can reach your data.
Deciding What to Patch First — CVSS, EPSS and KEV, and What Each Is For
CVSS is severity, EPSS is probability of exploitation, KEV is confirmed exploitation. They are not substitutes. Our own data across all 1,695 KEV entries: 64% score below CVSS 9 and 24% sit below EPSS 0.1 — so both 'patch the high scores' and 'ignore the low EPSS' fail in practice. Order by KEV, then EPSS, then CVSS, and set the deadline from your own exposure.
osv-scanner in Practice — pnpm, Ignoring CVEs, Offline Mode, and the Errors You Hit
Only the second-day questions, answered against the official docs. pnpm-lock.yaml is supported; ignores live in osv-scanner.toml under IgnoredVulns and can carry an expiry; offline mode is three flags with three different jobs. This site's view: a scanner reports known vulnerabilities, and says nothing about a version you pinned yourself going stale — that needs a separate mechanism.
Do Next.js and React Have a Lot of Vulnerabilities? What the CVE Data Actually Shows
The data says React core is almost untouched while Next.js CVEs are numerous and rising — but the substance is what matters: they land in middleware, caching, image optimization and Server Actions, with SSRF, deserialization and authorization bypass leading the CWEs. This site's conclusion is that treating Next.js as a front-end framework is the actual mistake. It is a server, so defend it like one: authorize again at the data, allow-list outbound fetches, and put Server Action endpoints behind auth.
One npm install Can Empty Your Credentials — Defending Against Supply-Chain Worms
Adding a dependency means running someone else's code with your privileges, so the defense belongs at install time. This site's view: signatures and provenance were walked straight through in this campaign, so they cannot be the basis of trust. What works is disabling install scripts by default, letting dependencies age a few days before adopting them, and keeping tokens short-lived and narrowly scoped. And if you suspect infection, the order in which you revoke matters.
Your Web Host Was Breached — What Can You Actually Do?
A provider-side compromise cannot be blocked by customer settings, so the defense shifts from prevention to blast-radius reduction. The second disclosure widened the scope to member contact and contract records, so it is no longer only a rental-server story. This site's view: treat everything on shared hosting as readable, and push secrets, credentials and backups outside the provider. For the August 2026 Sakura Internet disclosure, the critical skill is reading confirmed facts separately from the parts still under investigation.
File upload vulnerabilities — preventing web shells and RCE by design
The core of an upload hole isn't 'receiving a file' — it's where you put it and whether it can execute. Unauthenticated endpoint + no type validation + stored under the web root + scripts run there = web shell → RCE. Defend in layers: (1) auth/permission + CSRF on the endpoint, (2) server-side allow-list + content inspection, (3) store outside the web root (or disable execution), (4) randomize names, never trust user paths. Not one wall — a stop at every step.
Added a login and called it secure? — authentication vs authorization
Authentication = verifying who someone is; authorization = deciding what they may do. They're different, and adding a login is not authorization. Without owner (user_id) scoping on data, 'logged in = sees all data' — the top-ranked OWASP Broken Access Control. Add an open registration scaffold and a stranger can sign up and walk in. Defenses: scope every query to the owner, close unneeded registration, defense-in-depth, audit/access logs before an incident, detect new sign-ups.
How do people store passwords? What the data shows — and the safe way
Representative surveys show ~54% rely on memory, ~33% write passwords on paper, and only ~36% use a dedicated password manager — with ~25% reusing passwords. Meanwhile Verizon's DBIR found credential compromise involved in ~38% of breaches and that ~74% of passwords in breach data were reused. In short: the popular storage habits are exactly what attackers exploit. The safe foundation is a manager (unique password per site) plus passkeys/MFA on your key accounts.
How to store passwords safely — the right way to hash and salt
A practical guide to storing passwords safely on the server. Understand why plaintext, encryption, and raw hashes all fail, then converge on one answer: a per-user salt plus a deliberately slow hash (Argon2id recommended, bcrypt/scrypt as alternatives). Don't roll your own — use the standard function, raise the cost over time, and migrate weak hashes by re-hashing on login.
Security for the AI era: the basics to lock down now (priority checklist)
AI mostly amplifies attacks on EXISTING weaknesses (unpatched CVEs, reused passwords, exposed secrets) rather than inventing new ones — found automatically, fast, at scale. So the best preparation is locking down the basics in the right order: CVE patching + dependency monitoring, kill reuse + MFA, remove exposed secrets, least privilege, shrink the public surface, logs/IOCs, backups.
What works (and what doesn't) for AI-era security — why small sites get hit too
Four AI-era myths corrected: (1) too small to be targeted → automation removes 'a human picks you'; (2) needs a special new control → the basics still win; (3) a product makes you safe → prevention design before detection; (4) AI code is fast so it's safe → it ships with vulns, review before publishing. What works is the boring basics in the right order.
A phishing email forged your own domain? Spoofing vs a breach, and how to stop it
A suspicious email that appears to come from your own domain is usually not a breach — it's a forged From, because SMTP lets anyone write the From line. Reading the headers (Authentication-Results, Received, Reply-To) tells a breach from a forgery. The main reason it reaches your inbox is a missing DMARC policy. Fix it with SPF → DKIM → DMARC (p=none → reject).
Backup essentials: the 3-2-1 rule and a recovery plan that survives ransomware
'I have a backup' isn't enough — only a backup you've verified you can restore is real. The basics: the 3-2-1 rule (three copies, two media types, one offsite). For ransomware you also need at least one 'offline or immutable' copy — an always-connected backup gets encrypted along with the original. Cloud sync is not a backup (it replicates deletions and encryption too). Versioning and a periodic restore test complete the practice.
Stop secrets before they commit with gitleaks: catch API-key leaks before the push
Secrets can't be 'deleted after they leak.' Once committed, a secret stays in Git history, and once pushed it must be treated as leaked — the key needs revoking/rotating. gitleaks is a free tool that scans the whole repo and commit history with regex/entropy to find API keys, private keys, and tokens. The core of the defense is two gates: a pre-commit hook that stops it locally before the push, and CI/cron that catches what slips through. .gitignore only prevents new tracking — it can't detect, so you still need a scanner.
Choosing MFA the right way: what 'phishing-resistant' means, and why SMS is weak
MFA is a second lock so a leaked password alone can't get you in — but what you turn on changes its strength by three tiers. SMS/email codes fall to relay phishing and SIM-swap; authenticator apps (TOTP) are mid; passkeys/security keys (FIDO2) can't be presented to a fake site at all — that's phishing resistance. Top priority: put phishing-resistant MFA on the keys to the kingdom (email, domain, payments). Storing recovery codes and having a backup factor complete the setup.
Still on Windows 10? The security risks of running it after end of support
Windows 10 hit end of support on October 14, 2025. The core risk of staying is that newly found holes are never patched (forever-days) and pile up, making the machine a favored target. Consumer ESU is a one-year, security-only stopgap through October 13, 2026 (free enrollment routes exist, but the EEA free first year doesn't apply to most regions). The real fix is moving to Windows 11 or replacing the hardware — use ESU only as a bridge until that migration is done.
BitLocker vs 'Device encryption' — the same technology, full version vs automatic lite
BitLocker and Device encryption share the same encryption engine. Device encryption = the automatic, lite version that works on Home (auto-on with a Microsoft account, recovery key auto-escrowed, minimal options). BitLocker = the full version on Pro+ (startup PIN, external-drive encryption via To Go, fine control). For individuals, being auto-encrypted plus knowing where the recovery key is is usually enough. The state matters more than the name.
Fixing dependency CVEs for real: scan, fix, isolate, and keep watching
Vulnerability work isn't done when you 'fix it.' Done = 1) scan, 2) fix, 3) isolate/hand off, 4) monitor. Until monitoring (daily change-detection) is in place, it's incomplete — dependencies turn vulnerable again tomorrow. A perfect fix that the next deploy overwrites is worth zero. Small teams stay safe with two disciplines: automated change-detection and 'local→push→deploy.'
Securing a laptop you carry around — protecting against theft, loss, and shoulder-surfing
Carrying a laptop assumes you'll lose it or it'll be stolen. The real defense is designed so a loss doesn't leak the contents: disk encryption (BitLocker/FileVault), a strong login with a short auto-lock, and remote wipe/locate. With HTTPS everywhere, public-Wi-Fi sniffing is lower priority; the real threats are rogue APs, shoulder-surfing, and walking away. Don't over-trust a VPN — harden the device first.
Installing and using osv-scanner: find CVEs in your dependencies
osv-scanner scans lockfiles and containers to surface CVEs in your dependencies, free. This walks through install, run, and CI integration, plus when to use it vs npm/pnpm audit vs Dependabot. This site's view: the right tool is decided by YOUR setup — reach for osv-scanner on multi-ecosystem or GitHub-free projects, and the bundled pnpm audit for a single npm tree.
Are password managers safe? How they work, cloud vs local, and how to choose
A password manager is safer than reuse or plaintext storage. The key is zero-knowledge encryption: your master password decrypts the vault only on your device, the provider holds only ciphertext, so a provider breach doesn't expose your passwords. The real single point is your master password plus vault MFA. Choose cloud (Bitwarden/1Password) or local (KeePass) by use.
The dangers of public Wi-Fi — the real risk isn't 'sniffing,' it's evil twins and ignored cert warnings
Public-Wi-Fi 'sniffing' is mostly mitigated by HTTPS and is lower priority now. The real risks are (1) connecting to an evil-twin fake AP yourself, (2) ignoring certificate warnings, and (3) exposing your device on the shared network. The strongest fix is surprisingly simple — use your phone's tethering, trust HTTPS and cert warnings, and don't auto-join unknown SSIDs. A VPN is the next layer.
Did you leave a secret file in a public directory? Audit your webroot
Anything in your webroot is fetchable by URL by anyone. A leftover token/credential JSON, .env, or backup means instant exposure — and if it came from a shared template, every site has the same hole. Fix: put only publicly-shareable things in the public dir, keep secrets outside the webroot at perms 600, and once you find one, audit every site and host.
The security baseline for indie devs and small operators: the whole standard set
The baseline isn't 'all equally important.' This site's priority order: 1) keys to the kingdom (MFA, domain, email), 2) secrets and code, 3) the app itself, 4) patch, detect, recover. With finite time, fill it top-down. Most serious breaches come not from novel attacks but from a gap in this foundation.
The security baseline for mid-to-large organizations: the standard foundation for teams
At scale the baseline shifts from a 'checklist' to 'programs with owners.' The priority order matches the indie version: 1) identity, 2) secrets and supply chain, 3) app and infra, 4) detect and respond, plus a cross-cutting people-and-governance layer. The big change: the leading cause of breaches moves from slips to people, process, departed-employee access, and third parties.
Security inventory — 7 checks people running several servers overlook
For solo/small operators, incidents come less from missing controls than from untracked state. The boundary is the PC holding your keys. Tier 2FA by root of trust, matrix your SSH keys to kill duplicates/unused/orphans, remove plaintext passwords from the cloud, remediate reversibly one at a time, and keep secrets out of the ledger. Inventory before adding tools.
Self-hosted Git vs GitHub: which is actually more secure?
Self-hosting Git doesn't make you 'more secure' — it relocates the risk. The accidental-public-exposure class disappears, but patching the server, backups, and pre-commit secret detection move onto you. The right call if you pay the price; worse than GitHub if you neglect it. This site's view: self-hosting only works bundled with its compensating controls.
Smartphone security basics — protecting the device that holds your keys, vault, and ID in one
A phone concentrates 2FA, email, banking, and ID into one single point of failure. The real defense isn't a security app: (1) a strong lock + short auto-lock (the passcode is the encryption key); (2) automatic OS/app updates; (3) official store + permission review; (4) set up remote lock/wipe in advance; (5) keep a backup of your 2FA. iOS/Android already encrypt and sandbox by default.
Don't give root keys to environments that can be compromised: SSH key least privilege
Registering a root key into production from an ephemeral, compromisable environment (GPU pod, CI runner, throwaway VM) means that the moment the environment is compromised, production is taken with root. Fix: no root keys on ephemeral environments; remove keys when unused; if needed again, use a non-root user plus a command-restricted key that limits the key to one operation. A reused key is your most critical asset — never build a 'one leak, everything' setup.
Is storing your passwords in Google Drive safe? How to keep them properly
Keeping passwords in a plaintext Google Doc/Sheet is dangerous: one Google account becomes the single point of failure for every password — account takeover, a rogue connected app, or phishing leaks them all at once. The fix is a dedicated password manager (contents stay encrypted even when synced). If you must use Drive, store only an encrypted vault file and put phishing-resistant MFA on the account.
Why an OpenAI Account Gets Banned: Stolen API Keys and the Distillation Policy
When a stolen API key is abused for 'distillation', even the victim's account can be auto-suspended. A defensive, de-identified guide to the mechanism, prevention, and appeals.
What is X-Forwarded-For (XFF) spoofing — the trusted-proxy config trap
XFF is a client-forgeable header. A blind scanner hides injection probes in a spoofed XFF; 'trust all proxies (wildcard)' lets it through. Patch = sanitize the IP header at the boundary; root fix = trust the right proxies (or none). Zero impact still left a setting to fix.
AI-written code leaked an API key and ran up fraudulent charges — the real cause was an unpatched CVSS 10.0
The bill spike was a symptom. The real cause was an unpatched, public CVSS 10.0 RCE. An anonymized case, distilled into defensive lessons.
Security basics: what's actually dangerous about .env and API keys
Start here. Understand what happens when .env and API keys leak (spare key → impersonation → fraudulent billing), then adopt four habits today: don't expose them, don't commit them, rotate everything if leaked, and self-check.
Laravel apps' .env was readable by the whole world — the most common shared-hosting mistake
The cause: the whole app sat under the web root; only public/ should be visible. Fix in three steps — .htaccess first aid, rotate keys, restructure — then prevent it with process.
Running Next.js safely: not falling behind on published CVEs
The top framework risk is neglected published CVEs. Defend with four pillars: judge by the running version, monitor with Dependabot/osv-scanner, update fast, and run least-privilege. This site's view: indie devs lose not on knowledge but on operational continuity — win with a system that doesn't miss, not with speed.
Keeping .env off the public web on shared hosting
The real fix: app body outside the docroot, only public/ exposed. Stop the bleeding with .htaccess, make it permanent by restructuring, then self-check. This site's view: this isn't one person's slip but an industry-standardized bad pattern — fix it with process, not vigilance. bootstrap-redirect beats symlink.