Glimpse is a privacy-focused missed-connections application built as a pnpm TypeScript monorepo. The production system consists of an Express 5 API (artifacts/api-server) and an Expo / React Native client (artifacts/glimpse), with Clerk for authentication, PostgreSQL via Drizzle for application data, and Replit/GCS-backed object storage for uploaded media. Users authenticate, record coarse location presence, post glimpses about people they saw, respond to matching glimpses, and chat after mutual confirmation.
Production scope for this scan is the API server plus the shipped Glimpse client and web build paths. The mockup sandbox is development-only and should be ignored unless production reachability is demonstrated. Assume NODE_ENV=production in deployed environments; TLS is platform-managed.
- User accounts and sessions — Clerk identities, bearer tokens, and local user records. Compromise would allow impersonation and unauthorized access to profile, discovery, and messaging surfaces.
- Location presence and glimpse data — coarse presence buckets, event times, place labels, and authored glimpses. This data is privacy-sensitive because it reveals where and when a user was likely present.
- Private interactions — responses, matches/connections, and chat messages. Exposure would reveal intimate social interactions and inferred relationships.
- Profile data and uploaded media — display names, bios, optional demographic details, and profile photos stored in object storage. This data is user-controlled but privacy-sensitive.
- Application secrets and paid integrations — Clerk secret key, Google Places API key, database connectivity, and object-storage signing capability. Abuse would enable account compromise, budget burn, or data access.
- Service availability and abuse budget — database capacity, Places API spend, storage bandwidth, and route-level compute. Unbounded authenticated abuse can still meaningfully impact the product.
- Client to API — all mobile/web client traffic crosses into the Express API. The client is untrusted; every protected action must be authenticated and authorized server-side.
- API to Clerk — the API relies on Clerk-validated identity claims and user lookups. Any confusion about token source, proxying, or session validation can become spoofing or CSRF risk.
- API to PostgreSQL — all persistent state flows through the DB layer. Authorization failures here can leak or tamper with private location, chat, or profile data.
- API to object storage — upload signing and object serving cross a storage trust boundary. Access control mistakes can expose or let users bind media they do not own.
- API to third-party services — Google Places is called with a server-side API key. Abuse or missing controls can burn budget or leak operational details.
- Public to authenticated surfaces — most API routes are authenticated, but health and storage-serving endpoints are public. This boundary must stay explicit and minimal.
- Authenticated user to other authenticated user data — discovery, responses, connections, and chat all expose cross-user information. Ownership and privacy rules must be enforced per object, not just per session.
- Production entry points:
artifacts/api-server/src/index.ts,artifacts/api-server/src/app.ts,artifacts/glimpse/app/_layout.tsx. - Highest-risk code areas:
artifacts/api-server/src/routes/, especiallystorage.ts,photos.ts,presence.ts,glimpses.ts,responses.ts,chat.ts,connections.ts, andme.ts. - Cross-user data helpers:
artifacts/api-server/src/lib/profileSummary.tsand DTO helpers in the routes above. - Safety enforcement anchor:
artifacts/glimpse/lib/moderation.tsshould be treated as advisory unless the same rules are enforced inartifacts/api-server. - Public surfaces:
/api/healthz,/api/storage/public-objects/*,/api/storage/objects/*, and production Clerk proxy path/api/__clerk/*. - Authenticated surfaces:
/api/me*,/api/presence,/api/glimpses*,/api/responses*,/api/connections*,/api/chat*,/api/places*,/api/reports,/api/events, upload-URL issuance under/api/storage/uploads/*. - Dev-only areas usually out of scope:
artifacts/mockup-sandbox, local build scripts, temporary demo assets, and non-production development helpers unless they affect shipped runtime behavior.
The system trusts Clerk-authenticated identity at the API boundary. All routes that read or mutate user-scoped data must require a valid Clerk session or bearer token, and public routes must remain intentionally public. The application must not allow cross-origin or proxy behavior that lets an attacker make authenticated state-changing requests from another site using a victim's browser context. Location and co-presence claims should also be treated as attacker-controlled input unless the server can prove or strongly bind them to prior authorized state.
Users can submit profiles, glimpses, responses, reports, chat messages, location presence, and media references. The server must validate every payload and must enforce ownership when mutating or attaching stored objects. Any route that accepts user-controlled identifiers must prove the caller is authorized to act on that object rather than trusting client-supplied IDs or paths. Safety and moderation rules that matter for production abuse prevention must be enforced at the API boundary; client-side filtering is only advisory.
The core product handles sensitive location-adjacent data and private conversations. Discovery and response flows must only reveal data allowed by the matching model, block rules, and connection state. Object storage routes and profile summaries must not expose media or metadata that is intended to remain private. When the product promises coarse or fuzzy location disclosure, DTOs returned to other users must not include exact coordinates or precise timestamps that bypass those privacy guarantees. Logs and error responses must avoid leaking tokens, secrets, or unnecessary internals.
Authenticated users can still be abusive. Presence ingestion, messaging, glimpse creation, reporting, and Places lookups all need bounded resource usage. Endpoints that write unbounded rows, generate paid third-party requests, or stream storage objects must have controls strong enough to prevent a single account from materially degrading service or burning budget.
There is no explicit admin surface, so the main privilege boundary is user-to-user isolation. Users must not be able to read other users' private data, act on connections they do not belong to, confirm or decline responses for glimpses they do not own, or attach/access stored objects owned by someone else. All authorization checks must be enforced on the server even if the client UI already hides disallowed actions.