<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>chs.us — Carl Sampson</title><link>https://chs.us/</link><description/><language>en-us</language><managingEditor>carl.sampson@gmail.com (Carl Sampson)</managingEditor><webMaster>carl.sampson@gmail.com (Carl Sampson)</webMaster><lastBuildDate>Fri, 24 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://chs.us/tags/defense-in-depth/index.xml" rel="self" type="application/rss+xml"/><item><title>Multi-tenant isolation as defense-in-depth: when WHERE owner_user_id isn't enough</title><link>https://chs.us/2026/07/multi-tenant-isolation-defense-in-depth/</link><pubDate>Fri, 24 Jul 2026 00:00:00 +0000</pubDate><author>carl.sampson@gmail.com (Carl Sampson)</author><guid>https://chs.us/2026/07/multi-tenant-isolation-defense-in-depth/</guid><description>Every query that returns user data filters by owner. That&amp;#39;s the contract — and one forgotten WHERE clause leaks another tenant&amp;#39;s data. Here&amp;#39;s a second, automatic layer that fails closed, built on a SQLAlchemy do_orm_execute hook.</description><category>Security</category><category>Multi-Tenant</category><category>Sqlalchemy</category><category>Postgres</category><category>Appsec</category><category>Defense-in-Depth</category><category>Oast</category></item></channel></rss>