NoSQL Shouldn’t Mean NoSecurity
summary
Demonstrates that unsecured document stores really get compromised: spins up an unsecured MongoDB on Azure, imports fake credit‑card JSON, leaves a honeypot live for six weeks and watches access patterns; cites Shodan showing ~61,000 exposed MongoDB instances and public incidents where attackers leave "SEND 0.2 BTC TO THIS ADDRESS 1zaGVjj9NcyvDLyYpCh33Msq TO RECOVER YOUR DATABASE!"; shows injection and server‑side JS risks, then gives concrete fixes: require auth, CI checks, log alerts, PII scans, and hire audits.
AI-written summary · about
chapters (18)
- 0:00Introduction
- 1:25Speaker introduction
- 2:52NoSQL history
- 6:27Why NoSQL grew
- 8:56NoSQL trade-offs
- 10:20NoSQL security incidents
- 14:20Unsecured MongoDB honeypot
- 22:31Public database exposure
- 22:51Security measures for devs
- 24:37NoSQL injection flaws
- 27:49PII handling in NoSQL
- 29:55Security audits matter
- 33:33Document DB benefits
- 35:16Vendor security recs
- 38:52Training developers
- 41:43Breach costs
- 44:08Summary
- 46:55Q&A
related talks
35mNoSQL Is Not NoVulnerable
38mNot all data is created equal: NoSQL
05mNoSQL injections in Node.js: The case of MongoDB
01h 01mNoSQL: An Analysis
29mGraphQL Security Best Practices and Hardening
20mStop Doing Stupid $%^--How Not to Secure Your Environment
23m{JS-ON: Security-OFF}: Abusing JSON-Based SQL Queries
45mNoSQL: Death to Relational Databases