SECURITY CASE STUDY
PublishedSecureDesk
Security Assessment & Hardening
Developer-led security assessment of a multi-tenant SaaS application, covering authentication, authorization, PostgreSQL Row Level Security, API protection, and private file handling.
- Focus
- Cyber Lab
THE TECHNOLOGY
- Next.js
- TypeScript
- Supabase Auth
- PostgreSQL
- Supabase Storage
- Node.js
- Docker
- pgTAP
DEVELOPER-LED SECURITY ASSESSMENT
01 — Project Context
SecureDesk is a multi-tenant client support application for account approval, organization access, projects, support tickets and private attachments. Different business roles work with information belonging to specific organizations, so identity, current permissions and private file handling must be evaluated together.
This developer-led assessment reviewed defensive controls through positive and negative local scenarios, automated verification and documented regression work. The focus was whether authorized operations worked while selected cross-organization requests, forged parameters and stale permissions were rejected.
The October 26, 2026 documentation audit reviewed seven assessment documents, selected source and test definitions, and saved historical results. It did not rerun the SecureDesk test suites or validate a current production deployment. This portfolio presents concise reviewed summaries; it does not expose the underlying private logs or fixtures.
02 / SECURITY ARCHITECTURE
Connected controls.
Distinct responsibilities.
Identity, business authorization, database access and private bytes form different trust boundaries. Each needs its own evidence.
Select a boundary to explore its responsibility.
Request boundary
Next.js application
Server routes and native actions validate incoming data and verify the requesting identity before protected business operations. A client-provided role or object identifier is not a permission.
Conceptual trust boundaries from the reviewed design, not a network scan or a current deployment attestation. Requests may cross several boundaries; this is not a literal packet-flow diagram.
03 / TESTING METHODOLOGY
Test what should work.
Then test what must not.
Positive & negative scenarios
Controlled fictional accounts, organizations and permissions exercise permitted operations alongside deliberately unauthorized requests.
Authentication & authorization
Email confirmation, account approval, company assignments, role changes and existing sessions are evaluated as separate controls.
Native HTTP, API & RPC checks
Node HTTP requests and separate cookie jars exercise native actions and selected API/RPC operations. These are not a comprehensive interactive-browser security test.
PostgreSQL / pgTAP verification
Selected SQL checks distinguish grants, RLS enablement, returned-row assertions and privileged-function protections.
File & Storage validation
Selected attachment scenarios examine authorization, malformed content, direct Storage access, SHA-256 integrity and private responses.
Regression & evidence review
The documented CSP correction was followed by affected regression sets. The later documentation audit reviewed records and definitions without rerunning the suites.
04 / HISTORICAL VERIFICATION RESULTS
Recorded checks.
Explicit boundaries.
Historical local verification · October 2026 · Gate 6
SQL/RLS checks
4,177PASS recorded historicallyAuth/API/native HTTP checks
4,390PASS recorded historicallyUnit checks
51PASS recorded historically8,618 historical verification checks
- Historical Gate 6 records
- Later quarantine-transfer adaptation
- Documentation audit; no security suites rerun
05 / SELECTED SECURITY INVESTIGATIONS
Six investigations.
Follow the evidence.
Expand an investigation for its objective, scenario, expected behavior, recorded result, significance and limits.
Authentication & Account ApprovalSEC-002 · SEC-003
- Security objective
- Keep verified identity separate from permission to enter an organization's workspace.
- Test scenario / methodology
- Local and native HTTP tests exercised invalid registrations, confirmed-but-pending accounts, injected role/approval metadata and unauthorized self-approval attempts.
- Expected behavior
- Invalid input cannot create a usable account, and email confirmation alone cannot grant protected company access or a privileged business role.
- Recorded result
- Selected historical local and web authentication checks passed. Manipulated registration fields did not grant the tested privileged roles; confirmed pending accounts remained restricted.
- Security significance
- Authentication answers who the user is. Approval and trusted business permissions decide what that identity may do.
- Relevant limitations
- These are selected historical scenarios. Current Auth test definitions include later changes, and hosted provider settings were not reverified by the documentation audit.
Permission RevocationSEC-003 · SEC-004
- Security objective
- Ensure a valid existing session does not preserve business access after the relevant permissions are removed.
- Test scenario / methodology
- Administrators revoked Staff company assignments or Admin organization scope while the affected user retained a session. Tests replayed forms captured before revocation and exercised role changes.
- Expected behavior
- Subsequent scoped reads and writes are denied; old forms cannot recreate revoked access. An unrelated authorized company assignment remains separate.
- Recorded result
- The recorded local and HTTP access checks rejected the selected post-revocation operations. Restoring a Staff role did not automatically restore historical organization assignments.
- Security significance
- Authorization must use current trusted permissions, not just an earlier successful sign-in.
- Relevant limitations
- Immediate business-access denial in these workflows is not immediate global invalidation of all provider JWTs. Previously issued access tokens may remain usable until expiry.
Tenant Isolation & RLSSEC-003
- Security objective
- Protect organization-scoped resources across application and database boundaries.
- Test scenario / methodology
- Selected tests changed organization identifiers, submitted copied administrative forms and attempted foreign-company operations. PostgreSQL/pgTAP checks examined privileges, RLS configuration and seeded-row counts.
- Expected behavior
- Unauthorized company operations fail. Database privilege restrictions and RLS row filtering are verified as separate mechanisms.
- Recorded result
- Historical access checks rejected selected cross-company operations; the SQL/RLS regression recorded 4,177 PASS. Reviewed matrix assertions expect one seeded organization for an assigned Admin and zero for a pending caller.
- Security significance
- Resource identifiers are not credentials. Application authorization, SQL grants, row policies and privileged functions require distinct checks.
- Relevant limitations
- SQL error 42501 can show privilege enforcement without exercising RLS. Successful SELECT execution does not prove isolation, and a positive one-row count does not establish the returned row's identity. Complete policy and endpoint coverage is not established.
API Security & Parameter TamperingSEC-002 · SEC-004
- Security objective
- Reject forged roles, manipulated object identifiers, copied forms and stale authorization data.
- Test scenario / methodology
- Native HTTP/form-action and selected API/RPC tests submitted unexpected role and permission fields, mismatched identifiers, duplicate inputs, copied administrative forms and outdated revisions.
- Expected behavior
- Trusted server state governs privileged decisions. Unauthorized or stale requests cannot create elevated roles, cross-company writes or revoked assignments.
- Recorded result
- Selected historical authentication, access-management and retry records report expected rejections. The eight API-related regression groups are subsets of the broader 4,390 Auth/API/native HTTP total.
- Security significance
- Hidden inputs and client state do not form a security boundary; authorization must be evaluated for the current actor and resource.
- Relevant limitations
- Several logs contain aggregate totals. An assertion, request and attack are different units. These results do not establish universal IDOR/BOLA, injection or endpoint coverage, or a complete interactive-browser assessment.
Private File SecuritySEC-005 · SEC-001
- Security objective
- Deliver only permitted, validated private attachments with appropriate integrity and download protections.
- Test scenario / methodology
- The reviewed native-upload and download scenarios cover malformed files, unauthorized users, direct Storage restrictions, server-derived SHA-256 verification and deliberate alteration of stored fixture bytes.
- Expected behavior
- Invalid or unauthorized files are refused. A size/checksum mismatch prevents delivery; allowed downloads use restrictive caching, MIME and attachment handling.
- Recorded result
- The historical attachment suite records 341 PASS. Reviewed definitions deny an altered download, permit it after the original bytes are restored and assert selected private-download headers, including nosniff, no-store and attachment disposition.
- Security significance
- Authorization, structural validation, protected Storage, integrity and safe delivery complement one another.
- Relevant limitations
- The current attachment script differs from its historical fingerprint. Later quarantine, upload-capability and replay definitions are not all established by the October 8 count. Structural validation is not antivirus scanning; integrity also depends on trusted metadata.
CSP Conflict & RemediationSEC-001 · SEC-005
- Security objective
- Preserve the restrictive policy intended for private attachment downloads when general response security handling also applies.
- Test scenario / methodology
- Historical verification reproduced a conflict between the general response CSP and the dedicated private-download policy. Response handling was corrected and affected regression sets were repeated.
- Expected behavior
- Designated private download responses retain the policy: sandbox; default-src 'none'. Other file authorization and response controls remain separate layers.
- Recorded result
- The Gate 6 report records the conflict as reproduced, corrected and regression-tested. Related proposal and attachment sets reported passing results after the documented correction.
- Security significance
- Protective controls must be tested together: an integration conflict can undermine an otherwise appropriate individual policy.
- Relevant limitations
- Passing whole regression sets is not a count of individual CSP tests. Selected local HTTP/header evidence does not establish complete production header coverage, nonce propagation or browser-level enforcement.
06 / EVIDENCE & TECHNICAL DOCUMENTATION
Five technical areas.
Reviewed summaries.
Prepared from the five assessment documents, the evidence index and the reviewed case-study narrative. Full technical files are maintained separately; raw logs, credentials and operational fixtures are not included here.
Read technical documentation on GitHub
SEC-001CSP & HTTP Headers
Nonce-based policy generation, header configuration and the documented private-download CSP correction.
Evidence basis
Reviewed implementation, ten historical security-control unit tests and selected local HTTP/header evidence.
Boundary
Unit outputs, HTTP assertions and actual browser enforcement have different scopes; current production coverage remains unverified.
SEC-002Authentication & Session Security
Email confirmation versus approval, request-scoped sessions, registration protection, logout and attempt limiting.
Evidence basis
Selected local Auth, native HTTP/cookie-jar and registration-retry results; reviewed test definitions.
Boundary
Historical results are distinct from current definitions and hosted settings. Business revocation is not universal JWT revocation.
SEC-003Access Control, RLS & Tenant Isolation
Trusted roles, organization scope, permission revocation, SQL privileges, selected row counts and privileged functions.
Evidence basis
Historical application access checks and the SQL/RLS regression, with selected matrix assertions reviewed.
Boundary
RLS enabled, privilege denial and effective row isolation are not interchangeable evidence.
SEC-004API Security & Request Integrity
Selected cross-company operations, forged parameters, stale forms, native actions and API/RPC boundaries.
Evidence basis
Eight mapped API-related historical groups plus selected source assertions and detailed Auth/access records.
Boundary
Aggregate PASS totals do not establish every endpoint, assertion or browser interaction was covered.
SEC-005File & Storage Security
Attachment authorization, validation, Storage restrictions, SHA-256 integrity and safe private downloads.
Evidence basis
The historical 341-check attachment result and separately reviewed current file-handling definitions.
Boundary
Later quarantine expectations remain distinct from Gate 6; malware scanning, capability expiry and all-failure cleanup are not guaranteed.
07 / LESSONS LEARNED & LIMITATIONS
Assurance needs context.
Security controls have to work across layers. Negative tests, current permissions and regression checks reveal behavior that isolated happy-path tests can miss. Passing results support defined scenarios, not permanent or universal security claims.
Process-local rate limiting
Application counters reset with the process and are not shared across instances. They do not replace provider or infrastructure abuse controls.
Session and JWT lifetime
Application logout, current business permissions and provider token expiry are separate controls. Existing access tokens may remain usable until expiry.
File scanning and integrity
Structural validation is not comprehensive malware scanning. A checksum also depends on protecting trusted metadata; capability expiry and cleanup were not measured under every failure condition.
Privileged service-role credentials
Exposure of privileged credentials could bypass ordinary boundaries. This is a residual risk, not a claim that a credential leak occurred.
Current deployment verification
Production authentication, headers, Storage configuration, operational logging and relevant backup/recovery behavior need separately scoped verification. Later Phase 7 records were not reverified by the documentation audit.
Historical provenance and coverage
The exact whole Git revision tested in Gate 6 is not established. Some current sources contain later changes; aggregate totals do not certify every endpoint, row policy or browser behavior.
Dependency lifecycle
The historical completion disclosed a development dependency High advisory. PASS did not mean a clean full dependency audit; its current status was not reassessed here.
This is a developer-led security assessment, not an independent penetration-test certification or a current production security guarantee.