> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.mythos.new/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.mythos.new/_mcp/server. # Project security > Run project scans, review findings, and check what a report covers before publishing. The Security view brings together the security findings for one project. Use it to review potential risks in the app, understand what needs a change, and check the result again after fixing it. Open the project and choose **More → Security**. Project admins can run scans and manage ignored findings. The report is separate from your account's two-factor authentication and workspace [Privacy and security settings](/introduction/privacy-security). ## Run a scan Choose the scan that fits the check you need: | Scan | What it does | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Basic security scan** | Checks source, possible exposed secrets, dependencies, and configuration guidance. Where a managed Supabase backend is attached and accessible, it also includes database security advisors. | | **Deep security scan** | Includes those checks and adds a project-specific review of application code. | Start with Basic to see the current checks and any missing coverage. Use Deep when you need a closer review of the project's behavior and permissions. A scan identifies issues; it does not silently rewrite the app. Wait for the scan result before treating the check as complete. If a request takes too long, use **Check results** to see whether a report was saved before starting another scan. ## Check the version and coverage A report applies to the project version it scanned. The banner shows the scanned version and when the scan completed. * **Results from another project version** means the project changed after that report. Run a new scan for the version you intend to publish. * **Current project version could not be verified** means the saved report cannot yet be compared with the current project. Choose **Check results**. * **Security coverage incomplete** means one or more checks did not finish or were unavailable. Read the coverage notices below the findings. For example, a database check may ask you to reconnect Supabase or review access to the managed backend. An external database that is not attached through the managed connection is not covered by that check. “No risks found in completed checks” does not mean the missing checks passed. Likewise, a completed scan with no findings is useful evidence about that scan, not a guarantee that every user action is secure. ## Review a finding Open a row under **Project risks** to read: * The problem and why it matters. * The affected file or location when available. * The **Recommended fix**. * Whether the next action is a **Project change**, **Connection action required**, or a **Mythos-owned dependency** issue. * Any linked background information. Start with the findings that could expose data or allow an unintended action. Read the explanation as well as the severity label: a dependency advisory still needs to be relevant to how your app uses that package. The **Mythos dependency maintenance** section tracks confirmed build-only or unused platform dependencies separately. Use the action owner shown in the report to decide whether you should change the app, reconnect a service, or seek help. ## Fix and verify For a project change, describe the specific finding in chat and ask for a focused fix. Include the affected page, file, or behavior rather than asking for an unrelated rewrite. ```text Review the security finding about reservation access. Explain which users can currently read a reservation, then fix it so only its owner can read it. Keep the staff workflow working. ``` After the change, check the behavior the finding concerned and run another scan. For an access rule, test with the relevant user roles: an allowed user, a user who should be denied, and a signed-out visitor when applicable. For a connection problem, resolve the connection or permission issue first, then rerun the missing check. Repeated code edits will not restore a revoked provider connection. See [Row-level security](/integrations/supabase#row-level-security) and [Storage policies](/integrations/supabase#storage-policies) for the distinction between app screens and backend access rules. ## Ignore a finding deliberately If a finding is a false positive, intended behavior, or a risk you have explicitly accepted, choose the matching **Ignore reason**, then **Ignore**. Review the evidence before making that choice. Ignoring records your decision; it does not fix the underlying behavior. An ignored finding remains marked so that you can revisit it and restore it when the decision no longer applies. For example, an intentionally public list may be correct for a product catalog but inappropriate for customer reservations. Decide based on the data and intended audience, not only on whether a screen looks right. ## Before and after publishing Review security again after changing authentication, data access, uploads, external actions, or dependencies. Use a report for the current version, resolve important findings, and inspect any incomplete checks before publishing. A code fix appears on the live site only after you [publish the updated version](/publishing/publish). Database or connected-service changes have their own effects, so review those changes separately rather than assuming a source-code revert will undo them. Continue checking the app as it evolves. Automated scans complement testing the real user flows and reviewing who can access the data. ## Further reading The [OWASP Top 10](https://owasp.org/www-project-top-ten/) explains common web application security risks and why they matter. Use it as background when reviewing your app's findings.