Maintainer: Adewale Samson Adeagbo
Last Updated: May 2026

The PostgreSQL (pgAdmin) Simulator is designed with a privacy-first, zero-server architecture. Here is exactly how your data is handled:

• User-provided SQL runs entirely inside the browser's WebAssembly sandbox (sql.js). It cannot access your filesystem, network, or other browser tabs.
• Imported CSV/JSON data is processed entirely in memory by PapaParse (for CSV) or the browser's native JSON parser. No data is uploaded.
• HTML escaping: All user-provided content rendered to the DOM is escaped via the eH() function (which replaces <, >, &, " with HTML entities). This prevents XSS attacks.
• No eval(): The app uses zero dynamic code evaluation.

• ✅ Use the app locally (open the HTML file directly on your device) for sensitive/confidential data
• ✅ Use Database Backup (Tools → Database Backup) regularly to save your work
• ✅ Clear your browser's localStorage if using a shared/public device: Chrome → Settings → Privacy → Clear browsing data → Cookies and site data
• ✅ Keep your browser updated to the latest version for the best WebAssembly security

• ⚠️ Public deployments have no authentication. If you deploy to a public URL (GitHub Pages, Netlify, etc.), anyone with the URL can access the app interface. Do not import sensitive/confidential data into a publicly-hosted instance.
• ⚠️ localStorage data persists across sessions. If on a shared device, your saved queries and history remain until cleared. Use the local file approach (Option A in Deployment Guide) for privacy.
• ⚠️ Browser extensions with access to all site data can technically read localStorage. This is true for all websites and is not specific to this app.
• ⚠️ The app does not encrypt localStorage data. Saved queries and history are stored in plain text. This is fine for SQL practice queries but do not save credentials or secrets in saved queries.

If you discover a security vulnerability, please report it responsibly.

Instead, contact the maintainer directly through private channels:

Adewale Samson Adeagbo

1. Description of the vulnerability — What is affected and how
2. Steps to reproduce — Numbered, specific instructions
3. Potential impact — What could an attacker do?
4. Suggested fix (if you have one)
5. Your preferred attribution — Do you want to be credited publicly in the CHANGELOG, or remain anonymous?

Confirmed vulnerabilities will be credited in the CHANGELOG and release notes (with attribution unless you prefer anonymity).

These are intentional design choices and are not considered security vulnerabilities:

If you need to use this app in an environment with stricter security requirements:

1. Host privately. Deploy the file on an internal server with your organization's authentication (LDAP, SSO, VPN).

2. Pin CDN versions. Edit the CDN URLs in index.html to use specific version hashes or host the libraries on your own infrastructure.

3. Add SRI hashes. Generate Subresource Integrity hashes for the CDN libraries and add integrity attributes to the <script> tags.

4. Self-host libraries. Download sql.js, Chart.js, and PapaParse and serve them from your own domain instead of CDN.

5. Set CSP headers. Configure your web server to send appropriate Content-Security-Policy headers.

6. Use a private browser profile. If using on a shared device, use a separate Chrome profile or always clear data after sessions.