For Compliance & Security

Security and audit built into the architecture

Your Challenge

In regulated industries, you need to know exactly what data goes where:

  • Which data is accessed by which endpoints?
  • Who accessed what data and when?
  • Are there hidden queries that bypass authorization?
  • Can you prove data wasn't accessed by unauthorized users?
  • How do you audit data lineage and dependencies?

Most APIs have hidden data flows you can't audit. FraiseQL makes everything visible.

Security by Architecture

✅ Single Source of Truth: Views

All data access goes through defined views:

Benefit:
  - One place to enforce access control
  - Easy to audit: "which data does this view access?"
  - Row-level security: Built into the view
  - Transparent: Anyone can read the SQL

CREATE VIEW v_user_for_tenant AS
SELECT * FROM tb_user
WHERE tenant_id = current_tenant_id;

No hidden queries. No bypasses. Just SQL.

✅ Row-Level Security (RLS)

Implement security at the database level:

-- PostgreSQL RLS Example
ALTER TABLE tb_user ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON tb_user
  USING (tenant_id = current_tenant_id);

Result:
  ✅ No query can read data from other tenants
  ✅ Security enforced at DB level (not app)
  ✅ Impossible to bypass from application
  ✅ Auditable: All access logged by database

✅ Data Encryption

FraiseQL works seamlessly with encryption:

  • ✅ Transparent Data Encryption (TDE) - at database level
  • ✅ Encryption at rest - managed by database
  • ✅ Encryption in transit - standard HTTPS + TLS
  • ✅ Field-level encryption - in application or view

✅ No Hidden Queries

Every query is explicit and auditable:

Traditional GraphQL:
  @resolver
  def user(parent):
    # Hidden query: db.find("SELECT * FROM users ...")
    return db.find_user_posts(parent.id)  # Another hidden query!
    # What other queries might be triggered?

FraiseQL:
  @fraiseql.query(sql_source="v_user")
  def user(id: ID) -> User:
    # Compiled to a SQL template at build time
    # Rust executes it — no runtime query construction
    pass

No hidden queries. Auditors see exactly what runs.

Audit & Logging

Query Audit Trail

Every query is traceable to its view:

Database logs (enable query logging):
  - Which view was accessed (e.g., v_user_sensitive)
  - Who accessed it (authenticated user)
  - When it was accessed (timestamp)
  - From which application (connection info)

Log every access automatically. No app-level logging needed.
Database is the source of truth for who accessed what.

Data Lineage

Easy to trace where data comes from:

GraphQL Query Request
    ↓
  Application logs: which resolver called
    ↓
  View: v_user_with_posts (explicitly named)
    ↓
  SQL View Definition: shows exact tables/joins
    ↓
  Tables: tb_user, tb_post (source tables)

Auditors can trace: "This data came from these tables, via this view."
No mystery. All transparent.

Change Audit

Track all changes to views and schemas:

Git + Code Review:
  ✅ Every view change is in version control
  ✅ Every change has commit history
  ✅ Every change was reviewed (PR)
  ✅ Every change is auditable

Deploy:
  ✅ fraiseql build validates schema
  ✅ Deployment logs what changed
  ✅ Rollback is clean and traceable

Result: Complete audit trail of all data access changes.

Compliance Frameworks

GDPR Compliance

FraiseQL architecture supports GDPR requirements:

  • ✅ Data Subject Access (DSA): Query specific user's data (filtered view)
  • ✅ Right to Erasure: Delete specific rows, views reflect immediately
  • ✅ Data Portability: Export via view (structured, auditable)
  • ✅ Audit Logging: All access logged at DB level

HIPAA Compliance

Healthcare data requires strict access controls:

  • ✅ Encryption at rest: Database TDE
  • ✅ Encryption in transit: HTTPS + TLS
  • ✅ Access controls: Views enforce RLS
  • ✅ Audit logging: Every access logged
  • ✅ Data integrity: Database constraints

SOC 2 Compliance

System organization control requirements:

  • ✅ CC6 (Logical Access): Views define access
  • ✅ CC7 (System Monitoring): Database logging
  • ✅ A1 (Control): Architecture is control
  • ✅ C1 (Confidentiality): Encryption built-in

PCI-DSS Compliance

Payment card data protection:

  • ✅ Encryption: TDE + field encryption
  • ✅ Access Control: Views + RLS
  • ✅ Audit Trails: Database logging
  • ✅ Vulnerability Management: No hidden queries

Threat Mitigation

SQL Injection

Traditional Risk: Dynamic SQL in resolvers can be vulnerable

FraiseQL Approach: Views are static SQL, parameterized queries

-- View is static SQL (no user input)
CREATE VIEW v_user AS
SELECT * FROM tb_user WHERE id = $1;

-- Compiled SQL template uses $1 placeholder
-- Rust runtime binds user_id at execution time

Result: SQL injection impossible.

Unauthorized Data Access

Traditional Risk: Resolver can bypass authorization

FraiseQL Approach: Authorization built into view

-- View enforces authorization
CREATE VIEW v_user_data AS
SELECT * FROM tb_user
WHERE id IN (
  SELECT authorized_users
  FROM tb_permissions
  WHERE user_id = current_user_id
);

-- No way to access unauthorized data
-- Even if app logic fails, DB prevents it

Information Disclosure

Traditional Risk: Resolver returns too much data

FraiseQL Approach: Views define exactly what data is returned

-- Public view (limited fields)
CREATE VIEW v_user_public AS
SELECT id, name FROM tb_user;

-- Internal view (all fields)
CREATE VIEW v_user_internal AS
SELECT * FROM tb_user;

-- No accidental data leakage
-- Auditor can verify what's returned

Privilege Escalation

Traditional Risk: Resolver uses wrong credentials

FraiseQL Approach: Database connection uses service account

-- Application runs as limited service account
database_connection:
  user: fraiseql_app (limited permissions)
  password: *** (rotated regularly)

-- Service account can only access defined views
-- Cannot access raw tables
-- Cannot escalate privileges

Result: Even if app is compromised, damage is limited.

Incident Response

Breach Investigation

When a breach is suspected, you can answer quickly:

  1. What data was accessed? - Check which views were queried (view logs)
  2. Who accessed it? - Database logs show authenticated user
  3. When was it accessed? - Timestamp in logs
  4. How was it accessed? - Which endpoint / query
  5. Was authorization bypassed? - Check RLS policies (enforced at DB level)

Result: Answer in minutes, not days. Architecture is self-documenting.

Rapid Remediation

Fix security issues quickly:

If a view exposes too much data:
1. Update the view (SQL change)
2. Run fraiseql build (validate)
3. Deploy (atomic)
4. Breached data no longer accessible
5. All future access denied

No resolver code changes needed.
No cache to clear.
No complex rollback.

Compliance Documentation

Data Flow Documentation

Automatically generate compliance documentation:

  • ✅ System Architecture Diagram (views show data flow)
  • ✅ Data Classification (which data in which view)
  • ✅ Access Control Matrix (who can access what)
  • ✅ Encryption Inventory (where encryption is applied)
  • ✅ Audit Logging Configuration (what's logged)

Audit Report Generation

Views make it easy to generate compliance reports:

SELECT
  view_name,
  accessed_by,
  access_time,
  data_accessed
FROM audit_logs
WHERE access_time BETWEEN start_date AND end_date
ORDER BY access_time;

Single query. Complete audit trail.
Export for compliance officer.

Ready for Certification

Get Started Learn More