Malinois
Security guides
Malinois Field Guide

AI app security checklist

Fast app builders shorten the path from idea to production, but they do not remove the owner’s security decisions. This checklist turns those decisions into a repeatable review you can run before launch and after every meaningful change.

Define what you are protecting

Write down the public hostname, hosting provider, database, authentication service, third-party APIs, and every place a secret is stored. If a component is missing from this map, it is likely to be missed during review.

Separate public data from private data. A page may be public while its underlying customer records, admin actions, storage objects, and service credentials must remain restricted.

Launch review

  1. Confirm ownership and scope

    Choose only production or staging URLs you control. Record which environment you are checking so a safe staging result is never mistaken for production.

  2. Test authorization boundaries

    Use ordinary user accounts to confirm that one user cannot read or change another user’s records. Check admin routes, object identifiers, exports, and file downloads.

  3. Review public assets

    Inspect rendered HTML and JavaScript bundles for credentials, internal endpoints, source maps, debug details, or configuration that should remain server-side.

  4. Check browser defenses

    Verify HTTPS and response headers for content loading, framing, transport security, MIME handling, referrer leakage, and unnecessary browser capabilities.

  5. Reduce dependency risk

    Remove unused packages, pin important versions, review build warnings, and confirm that updates come from the expected registry and maintainer.

  6. Prepare recovery

    Document how to rotate credentials, restore data, disable a compromised integration, contact affected users, and roll back a deployment.

  7. Verify the live release

    Deploy fixes, then check the public URL again. Save the date and result so the next review has a trustworthy baseline.

Evidence worth keeping

  • The exact hostname and environment that were reviewed.
  • A short list of findings, owners, fixes, and verification status.
  • Credential rotation dates without storing the credentials themselves.
  • A recovery note that another trusted operator can follow.

Make the checklist part of shipping

Run the short version for every release and the full version after authentication, database, hosting, or payment changes. A passive scan can catch visible regressions, while authorization and recovery checks still require the owner’s direct review.

Check the deployed app, not just the checklist

With the owner’s authorization, Malinois reviews public responses for exposed files, secrets, database access signals, and missing security headers.

Run a free passive scan

Passive external review only. No exploitation or penetration testing.

Continue the review

Security headers checklist

Understand the browser protections each response header adds and verify them without guesswork.

Read guide →

Prevent API key leaks in web apps

Keep provider keys out of public bundles, logs, repositories, and unsafe client-side workflows.

Read guide →