Security at FlintDB

Last updated: 9 July 2026

FlintDB is a GUI for Google Cloud Firestore and Firebase Authentication. Because it sits in front of your production data, we designed it so that FlintDB holds as little of your credential material and data as possible. This page describes, in plain terms, exactly what we store, what we never store, and the controls in place — every statement below reflects how the product is actually built.

1. Connection model — Google OAuth only, no service-account keys

The only way to connect a Firebase project is Sign in with Google (OAuth 2.0 Authorization Code flow with PKCE). We never ask for, accept, or store your service-account key. Service-account upload is disabled in the hosted service.
Access is per user: each workspace member signs in with their own Google account and FlintDB acts with that member's own Google IAM permissions. FlintDB does not proxy or share one person's credential with other members — if you don't have IAM access to a project, FlintDB can't give it to you.
Requested OAuth scopes: openid, email, datastore (Firestore read/write), cloud-platform.read-only, firebase.readonly, and identitytoolkit (Firebase Auth user management). You can revoke FlintDB's access at any time from your Google account permissions.

2. What we store — and what we don't

We store	We do not store
Your account identity: email address and Google account id (`sub`)	Your Google password (we never see it — authentication happens at Google)
Your Google OAuth refresh token, encrypted with AES-256-GCM before it is written to our database	Your service-account keys (FlintDB never accepts them)
Workspace metadata: workspaces, member roles, connected project ids and display names, saved queries, per-project settings	Bulk copies of your Firestore documents or Firebase Auth users. Queries are pass-through: results go from Google's API to your browser and are not warehoused in FlintDB's database. (Two opt-in exceptions: the Recovery feature keeps encrypted before-images of documents you edit or delete, for undo, then auto-deletes them; and Team-plan scheduled backups store compressed archives of the collections you choose, pruned automatically by your retention setting — you can download or delete them at any time.)
An audit log of mutations made through FlintDB: actor email, project id, action, path and timestamp	Third-party tracking or advertising cookies. FlintDB itself sets only a session cookie (plus a short-lived sign-in cookie during Google OAuth); optional product analytics, if enabled by the operator, are disclosed in the Privacy Policy

3. Encryption at rest

OAuth refresh tokens (SaaS) are encrypted with AES-256-GCM (authenticated encryption — tampering is detected, not just hidden) using a dedicated 256-bit key kept in the server environment, separate from the database. A tampered or undecryptable token is rejected and the user is asked to sign in again.
Recovery before-images — the document snapshots kept for the undo/restore feature are likewise encrypted at rest with AES-256-GCM, and auto-expire after the plan's recovery retention window.

4. Session and transport security

Sessions are stored server-side; the browser holds only an opaque session id signed with HMAC-SHA256 in an httpOnly, SameSite=Lax cookie, marked Secure in production. Signature checks use constant-time comparison.
The production app sets HSTS, a restrictive Content-Security-Policy, X-Frame-Options: DENY (no clickjacking) and X-Content-Type-Options: nosniff.
The OAuth flow uses PKCE plus single-use, expiring state values to prevent code interception and CSRF.
Signing out revokes the Google refresh token at Google and deletes it from our database.
Sign-in endpoints and write-heavy operations (bulk update, import) are rate-limited.

5. Access control — an honest note

FlintDB's workspace roles and collection ACL are an app-layer guardrail: they shape what teammates can see and do inside FlintDB. They are not an IAM or database-rule boundary — anyone who independently holds the underlying Google / Firebase credentials can bypass FlintDB entirely. Keep Firestore Security Rules and Google IAM as your real access control, and use FlintDB roles and ACL for day-to-day team hygiene.

Workspace RBAC: owner / admin / member / viewer, enforced per workspace on every API request. Viewers are read-only.
Optional per-member collection ACL: deny-by-default path patterns (e.g. customers/*/orders) with read or write grants.
Project protection (read-only / production-confirm) adds a UI-level safety net against accidental destructive writes.

6. Audit logging

Every successful mutation performed through FlintDB — document create, update, delete, import, collection copy, bulk update/delete, undo, recovery restore, backup and restore, settings, role, ACL and Auth-access changes — is recorded with the actor's email, project id, action, target path and timestamp, scoped to your workspace. Workspace admins can review the log in the Audit view.

7. Your data rights (PDPA / GDPR)

Delete your account — self-service. Deleting your account cascades: personal workspaces and their data, memberships, sessions, and your encrypted refresh token are removed, and FlintDB attempts to revoke the token at Google as well.
Delete a workspace — workspace owners can delete a team workspace and its stored metadata.
Revoke access at the source — removing FlintDB from your Google account permissions immediately invalidates the refresh token we hold.

See the Privacy Policy, PDPA notice and DPA for the full picture.

8. Reporting a vulnerability

If you believe you have found a security issue in FlintDB, please email support@saasthai.com with enough detail to reproduce it. We ask that you give us a reasonable window to fix the issue before public disclosure; we commit to acknowledging reports promptly and will credit researchers who wish to be named.

ความปลอดภัยที่ FlintDB

ปรับปรุงล่าสุด: 9 กรกฎาคม 2569

คำแปลภาษาไทยนี้จัดทำขึ้นเพื่อความสะดวกของผู้ใช้ หากมีข้อความขัดแย้งกัน ให้ยึดฉบับภาษาอังกฤษเป็นฉบับที่มีผลทางกฎหมาย

FlintDB เป็น GUI สำหรับ Google Cloud Firestore และ Firebase Authentication เนื่องจาก FlintDB ทำงานอยู่ด้านหน้าข้อมูลที่ใช้งานจริง (production) ของคุณ เราจึงออกแบบให้ FlintDB เก็บข้อมูล การยืนยันตัวตน (credential) และข้อมูลของคุณไว้ให้น้อยที่สุดเท่าที่จะเป็นไปได้ หน้านี้อธิบาย อย่างตรงไปตรงมาว่าเราจัดเก็บอะไรบ้าง ไม่จัดเก็บอะไรบ้าง และมีมาตรการควบคุมใดอยู่บ้าง — ทุกข้อความ ด้านล่างสะท้อนวิธีการสร้างผลิตภัณฑ์ตามจริง

1. รูปแบบการเชื่อมต่อ — ใช้ Google OAuth เท่านั้น ไม่ใช้คีย์ service-account

วิธีเดียวในการเชื่อมต่อโปรเจกต์ Firebase คือ เข้าสู่ระบบด้วย Google (OAuth 2.0 Authorization Code flow ร่วมกับ PKCE) เราไม่ขอ ไม่รับ และไม่จัดเก็บคีย์ service-account ของคุณ การอัปโหลด service-account ถูกปิดใช้งานในบริการ hosted
การเข้าถึงเป็นแบบ รายบุคคล: สมาชิกแต่ละคนในเวิร์กสเปซเข้าสู่ระบบด้วยบัญชี Google ของตนเอง และ FlintDB ทำงานด้วย สิทธิ์ Google IAM ของสมาชิกคนนั้นเอง FlintDB ไม่ส่งผ่านหรือแบ่งปัน credential ของบุคคลหนึ่งให้สมาชิกคนอื่น — หากคุณไม่มีสิทธิ์ IAM ในการ เข้าถึงโปรเจกต์ FlintDB ก็ไม่สามารถมอบสิทธิ์นั้นให้คุณได้
สิทธิ์ OAuth ที่ขอ: openid, email, datastore (อ่าน/เขียน Firestore), cloud-platform.read-only, firebase.readonly และ identitytoolkit (การจัดการผู้ใช้ Firebase Auth) คุณสามารถเพิกถอนสิทธิ์การเข้าถึงของ FlintDB ได้ทุกเมื่อจาก หน้าจัดการสิทธิ์ของบัญชี Google

2. สิ่งที่เราจัดเก็บ — และสิ่งที่เราไม่จัดเก็บ

เราจัดเก็บ	เราไม่จัดเก็บ
ข้อมูลระบุตัวตนของบัญชีคุณ: ที่อยู่อีเมลและ Google account id (`sub`)	รหัสผ่าน Google ของคุณ (เราไม่เคยเห็น — การยืนยันตัวตนเกิดขึ้นที่ Google)
refresh token ของ Google OAuth ของคุณ โดยเข้ารหัสด้วย AES-256-GCM ก่อนที่จะถูกเขียนลงฐานข้อมูลของเรา	คีย์ service-account ของคุณ (FlintDB ไม่รับเลย)
ข้อมูลเมตาของเวิร์กสเปซ: เวิร์กสเปซ, บทบาทของสมาชิก, id และชื่อแสดงของโปรเจกต์ที่ เชื่อมต่อ, คำสั่งสืบค้นที่บันทึกไว้, การตั้งค่ารายโปรเจกต์	สำเนาเอกสาร Firestore หรือผู้ใช้ Firebase Auth ของคุณทั้งก้อน คำสั่งสืบค้นเป็นแบบ ส่งผ่าน (pass-through): ผลลัพธ์ส่งตรงจาก API ของ Google ไปยังเบราว์เซอร์ และไม่ ถูกเก็บลงฐานข้อมูลของ FlintDB (มีข้อยกเว้นแบบเลือกใช้ 2 อย่าง: ฟีเจอร์ Recovery เก็บ before-image ที่เข้ารหัสของเอกสารที่แก้ไข/ลบ เพื่อย้อนกลับ แล้วลบอัตโนมัติ และ backup ตามตารางเวลา ของแพ็กเกจ Team เก็บไฟล์บีบอัดของ collection ที่คุณเลือก โดยลบชุดเก่าตามค่า retention อัตโนมัติ — ดาวน์โหลดหรือลบได้ทุกเมื่อ)
บันทึกการใช้งาน (audit log) ของการเปลี่ยนแปลงที่ทำผ่าน FlintDB: อีเมลของผู้กระทำ, id โปรเจกต์, การกระทำ, path และเวลา	คุกกี้เพื่อการติดตามหรือโฆษณาของบุคคลที่สาม FlintDB ตั้งเพียงคุกกี้เซสชัน (และคุกกี้ชั่วคราวตอนเข้าสู่ระบบ Google OAuth); product analytics แบบเลือกใช้ หากผู้ดูแลเปิด จะระบุไว้ในนโยบายความเป็นส่วนตัว

3. การเข้ารหัสขณะจัดเก็บ

OAuth refresh token (SaaS) เข้ารหัสด้วย AES-256-GCM (การเข้ารหัสแบบรับรองความถูกต้อง — ตรวจจับการดัดแปลงได้ ไม่ใช่ เพียงซ่อนข้อมูล) โดยใช้คีย์ขนาด 256 บิตที่กำหนดไว้เฉพาะ ซึ่งเก็บไว้ในสภาพแวดล้อมของเซิร์ฟเวอร์ แยกจากฐานข้อมูล โทเคนที่ถูกดัดแปลงหรือถอดรหัสไม่ได้จะถูกปฏิเสธ และระบบจะขอให้ผู้ใช้เข้าสู่ระบบ ใหม่
Recovery before-images — snapshot ของเอกสารที่เก็บไว้สำหรับฟีเจอร์ undo/restore ก็เข้ารหัสขณะจัดเก็บด้วย AES-256-GCM เช่นกัน และหมดอายุอัตโนมัติตามระยะเวลา recovery ของแพ็กเกจ

4. ความปลอดภัยของเซสชันและการรับส่งข้อมูล

เซสชันจัดเก็บไว้ฝั่งเซิร์ฟเวอร์ เบราว์เซอร์เก็บเพียง session id แบบทึบ (opaque) ที่ลงนามด้วย HMAC-SHA256 ในคุกกี้แบบ httpOnly, SameSite=Lax และทำเครื่องหมาย Secure ในการใช้งานจริง การตรวจสอบลายเซ็นใช้การเปรียบเทียบแบบ constant-time
แอปในการใช้งานจริงตั้งค่า HSTS, Content-Security-Policy ที่เข้มงวด, X-Frame-Options: DENY (ป้องกัน clickjacking) และ X-Content-Type-Options: nosniff
กระบวนการ OAuth ใช้ PKCE ร่วมกับค่า state แบบใช้ครั้งเดียวและ หมดอายุ เพื่อป้องกันการดักจับโค้ดและการโจมตีแบบ CSRF
การออกจากระบบจะเพิกถอน Google refresh token ที่ Google และลบออกจากฐานข้อมูลของเรา
ปลายทางสำหรับการเข้าสู่ระบบและการดำเนินการที่มีการเขียนข้อมูลจำนวนมาก (การอัปเดตเป็นชุด, การนำเข้า) มีการจำกัดอัตราการเรียก (rate limit)

5. การควบคุมการเข้าถึง — ข้อชี้แจงตามจริง

บทบาทในเวิร์กสเปซและ collection ACL ของ FlintDB เป็นเพียงแนวป้องกัน ระดับแอปพลิเคชัน (app-layer guardrail): ใช้กำหนดว่าเพื่อนร่วมทีมเห็นและทำอะไรได้บ้าง ภายใน FlintDB มันไม่ใช่ขอบเขตการควบคุมระดับ IAM หรือกฎของฐานข้อมูล — ผู้ที่ถือ credential ของ Google / Firebase พื้นฐานไว้เองสามารถข้าม FlintDB ได้ทั้งหมด ให้ใช้ Firestore Security Rules และ Google IAM เป็นการควบคุมการ เข้าถึงที่แท้จริง และใช้บทบาทกับ ACL ของ FlintDB สำหรับการจัดระเบียบทีมในแต่ละวัน

RBAC ของเวิร์กสเปซ: owner / admin / member / viewer บังคับใช้ต่อเวิร์กสเปซในทุกคำขอ API ผู้ใช้ระดับ viewer เป็นแบบอ่านอย่างเดียว
collection ACL รายสมาชิกแบบเลือกได้: รูปแบบ path ที่ปฏิเสธโดยปริยาย (deny-by-default) (เช่น customers/*/orders) พร้อมการให้สิทธิ์อ่านหรือเขียน
การปกป้องโปรเจกต์ (อ่านอย่างเดียว / ยืนยันสำหรับ production) เพิ่มชั้นความปลอดภัยระดับ UI เพื่อป้องกันการเขียนทำลายข้อมูลโดยไม่ตั้งใจ

6. การบันทึกการใช้งาน (Audit logging)

ทุกการเปลี่ยนแปลงที่สำเร็จซึ่งทำผ่าน FlintDB — การสร้าง, อัปเดต, ลบเอกสาร, การนำเข้า, การคัดลอก คอลเลกชัน, การแก้/ลบเป็นชุด, การ undo, การกู้คืน, การ backup/restore, การเปลี่ยนการตั้งค่า, บทบาท, ACL และสิทธิ์ Auth — จะถูกบันทึกพร้อมอีเมลของผู้กระทำ, id โปรเจกต์, การกระทำ, path เป้าหมายและเวลา โดยจำกัดขอบเขตอยู่ในเวิร์กสเปซของคุณ ผู้ดูแลเวิร์กสเปซสามารถตรวจสอบบันทึกได้ ในหน้า Audit

7. สิทธิ์เกี่ยวกับข้อมูลของคุณ (PDPA / GDPR)

ลบบัญชีของคุณ — ทำได้ด้วยตนเอง การลบบัญชีจะลบแบบต่อเนื่อง (cascade): เวิร์กสเปซส่วนบุคคลและข้อมูลในนั้น, การเป็นสมาชิก, เซสชัน และ refresh token ที่เข้ารหัสของคุณ จะถูกลบ และ FlintDB จะพยายามเพิกถอนโทเคนที่ Google ด้วย
ลบเวิร์กสเปซ — เจ้าของเวิร์กสเปซสามารถลบเวิร์กสเปซของทีมและข้อมูลเมตาที่ จัดเก็บไว้ได้
เพิกถอนสิทธิ์ที่ต้นทาง — การนำ FlintDB ออกจาก หน้าจัดการสิทธิ์ของบัญชี Google จะทำให้ refresh token ที่เราถือไว้ใช้งานไม่ได้ทันที

ดูภาพรวมทั้งหมดได้ที่ นโยบายความเป็นส่วนตัว, ประกาศ PDPA และ DPA

8. การรายงานช่องโหว่ด้านความปลอดภัย

หากคุณเชื่อว่าพบปัญหาด้านความปลอดภัยใน FlintDB โปรดส่งอีเมลถึง support@saasthai.com พร้อมรายละเอียดที่เพียงพอ สำหรับการทำซ้ำปัญหา เราขอให้คุณให้ระยะเวลาที่เหมาะสมแก่เราในการแก้ไขปัญหาก่อนการเปิดเผยต่อสาธารณะ เรามุ่งมั่นที่จะตอบรับรายงานโดยเร็ว และจะให้เครดิตแก่นักวิจัยที่ประสงค์จะระบุชื่อ