Malware Scanning SOP
Server-side scanner (maldet, ClamAV) vs plugin scanner (Wordfence) vs external integrity check. Layer them.

— Use a server scanner when: you control the box and want filesystem-wide detection independent of any compromised app.
— Use a plugin scanner when: you only have app access (managed host) and want WordPress-aware signatures and core-file diffing.
— Use external integrity monitoring when: you need detection a rooted box can't suppress. A compromised scanner reports clean.
— Prefer core-file comparison over signature-only: it catches modified wp-includes that no signature knows yet.
— Verify: plant a benign EICAR test file, confirm each layer flags it.

Run this when you suspect compromise or onboard a site.

ЕЮ Иванов продолжает кошмарить АффПапу, конторку, которая накинула говна на вентилятор этим летом. Тогда в AffPapa не знали, с каким говном идут бодаться, поэтому заслуженно проиграли. 😏

На этот раз ЕЮ зарегал товарный знак AffPapa — совсем скоро имя компании будет официально принадлежать ему. Чтобы убедиться в трушности мува, переходим по ссыл-Очке и вводим серийный номер: 2026793242. Там видим, что заявка на регистрацию подана лично Евгением Юрьичем.

Всё это выглядит забавно, но давайте не забывать, в какой сфере мы работаем и что реально может произойти с жирным троллем за воровство нейминга. Впрочем, толстому не привыкать отхватывать пиздов за проделки в интернете, поэтому ждем очередную фотку разбитого ебала и длинный пост с извинениями. 😏😏😏

В арбитраже денег нет 💵

Session Storage SOP: JWT vs Server-Side
Stateless JWT vs server-side sessions for authenticated apps. Choose by revocation needs.

— Use server-side sessions when: you need instant logout-everywhere and per-session revocation. Killing a row ends the session now.
— Use JWT when: you need stateless scale across services and can tolerate tokens living until expiry.
— Never store long-lived JWTs in localStorage: XSS reads them. Use HttpOnly cookies for the session token.
— If you use JWT, keep access tokens short (5-15 min) with a revocable refresh token server-side: that buys back revocation.
— Verify: log a user out, confirm their old token is rejected, not just removed from the client.

Run this when you design auth.

2FA Enforcement Layer SOP
App-level 2FA plugin vs reverse-proxy auth (Authelia, oauth2-proxy) in front of admin. Pick by what you protect.

— Use an app-level 2FA plugin when: you only protect one app's login and want it tied to that app's user roles.
— Use proxy-level auth when: you guard multiple backends (admin, staging, phpMyAdmin, Grafana) behind one gate, before the app even loads.
— Prefer the proxy for tools with weak or no native 2FA: it adds a factor without patching each tool.
— Never expose phpMyAdmin or /wp-admin without one of these layers.
— Verify: hit the protected path unauthenticated, confirm the gate intercepts before the backend renders.

Run this for every admin surface you expose.

Security Header Priority SOP
Which header buys the most safety per minute. Ship in this order.

— Ship Content-Security-Policy first: it's the heaviest lift but the only header that meaningfully blunts XSS. Start report-only.
— Ship X-Content-Type-Options: nosniff next: one line, stops MIME-sniffing attacks instantly.
— Ship Referrer-Policy strict-origin-when-cross-origin: cheap, stops leaking full URLs to third parties.
— Ship Permissions-Policy to disable unused features (camera, geolocation, microphone): shrinks attack surface for free.
— Skip X-XSS-Protection: deprecated and can introduce bugs. Skip X-Frame-Options if CSP frame-ancestors is set; don't double up inconsistently.
— Verify: scan with securityheaders.com, confirm each lands before moving on.

Run this on every new site.

WAF Baseline Ruleset SOP
Deploy a minimum rule set before tuning anything custom.

— Step 1: Enable the OWASP Core Rule Set at paranoia level 1. Higher levels false-positive on day one.
— Step 2: Block known-bad request patterns: ../ traversal, UNION SELECT, <script in query strings.
— Step 3: Geo-rate-limit /wp-login.php and /xmlrpc.php to 10 req/min per IP.
— Step 4: Run in detection mode for 72 hours. Review logs for legitimate hits.
— Step 5: Whitelist confirmed false positives by rule ID, never disable whole categories.
— Step 6: Flip to blocking mode.
— Verify: a test SQLi payload in a query param returns 403.

Run this every time.

New-Site Hardening SOP: 7 проверок до запуска любого проекта

1) Verify: домен, поддомен и зеркала не конфликтуют по редиректам. Один лишний цикл ломает трекинг и кеш.
2) Check: формы, кнопки и события аналитики на каждом экране. Если хотя бы один клик не уходит, воронка уже искажена.
3) Audit: пиксели, postback и UTM-метки на совпадение имен. Разные нейминги создают «потерянные» лиды.
4) Inspect: скорость, мобильную верстку и ошибки 4xx/5xx. Пользователь не будет чинить ваш лендинг за вас.
5) Confirm: текст оффера, дисклеймеры и способы связи совпадают везде. Любое расхождение повышает ручные проверки.
6) Test: отдельный сценарий для формы, чата и звонка. Каждый канал должен вести в один и тот же учет.
7) Freeze: список обязательных проверок в шаблоне запуска. Не держите это в голове — держите в SOP. Run this every time.

A few channels in the webmaster & site monetization space worth your feed:

— @NetworkMythHQ — We pressure-test what Ezoic, Mediavine and Raptive actually pay…
— @BidStack101 — Header bidding explained without the AdTech jargon: what Prebid,…
— @AdOpsWire — The insider feed for ad operations: GAM changes, network policy…
— @LiftLabRPM — Hands-on tests of every RPM lever — lazy load, refresh, sticky units,…
Follow the ones that fit — they're all part of the same network.