Security Guides
Passwords, MFA, devices, public Wi-Fi, servers, dependencies, Git, exposed environments — practical, goal-oriented guides to defenses you can apply today.
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.