Security status
This page is maintained by the Imagine Bot team to share our current security practices and the work we are doing to keep the platform safe. It is a transparency summary, not a third-party certification or audit report.
Latest scan: no critical issues
Our most recent security review completed without any critical findings. We did observe a small number of non-critical database warnings that we are addressing proactively. None of these warnings indicate an active vulnerability or data exposure in the app itself.
What we are addressing
The following items are on our security backlog and are being tracked to resolution.
Database function search paths
Some database functions were reported without an explicit `search_path` setting. This can make function behavior depend on the caller's schema context.
Planned actions
- Review all app-owned database functions and add `SET search_path = public` where missing.
- Document function ownership so internal platform functions are distinguished from app functions.
- Re-run the security scan after changes to confirm the warning is cleared.
Publicly executable SECURITY DEFINER functions
A small number of database functions run as `SECURITY DEFINER` and are currently executable by anonymous (not signed-in) users. These functions execute with the owner's privileges, so they should only be exposed when intentionally public.
Planned actions
- Audit each function to confirm whether it is intentionally public or app-internal.
- Revoke `EXECUTE` from `anon` on any internal functions, or switch them to `SECURITY INVOKER`.
- Move non-public functions out of the exposed API schema if they are not needed by the app.
Authenticated-only SECURITY DEFINER functions
Some `SECURITY DEFINER` functions are executable by any signed-in user. These are generally safe when scoped to the calling user, but we are verifying that none return or modify data belonging to other accounts.
Planned actions
- Verify each function validates `auth.uid()` or equivalent caller identity before acting.
- Tighten grants so functions are only executable by the roles that truly need them.
- Add review checks to the deployment checklist for new SECURITY DEFINER functions.
Our ongoing security practices
Row-level security (RLS) is enabled on user-facing database tables.
Authentication is required for resume, grading, and chat features.
Security scans are run before and after major deployments.
Dependencies are reviewed for known vulnerabilities as part of the build process.
User data is never shared with other users or returned to unauthenticated requests.
Have a security concern or vulnerability report? Contact us at the address listed in our site footer or through your account portal.