Authentication and sessions

Every route that needs a signed-in user enforces it on the server, not in the interface
Signing out, password changes and deactivation actually invalidate sessions server-side

Authorisation and object access

Every record lookup checks the requester owns or may see that record
Admin functionality has server-side role checks, not a hidden menu

Secrets

No API keys, tokens or credentials sit in the repository or the client bundle
Secrets live in a manager and get rotated when people or services leave

Dependencies

Every dependency was verified to exist, be maintained and be the intended package before install
A lockfile is committed and dependency vulnerability scanning runs in CI

Input handling and injection

Database access is parameterised or through an ORM everywhere, including the odd raw query
File uploads and user-supplied HTML are constrained, sanitised and stored out of the web root

Data storage defaults

The app collects only the data the product actually needs
Storage buckets and databases are private by default, with nothing world-readable

Errors and information leakage

Stack traces, debug endpoints and verbose errors are disabled in production
Errors are logged server-side without echoing internals back to the user

Deployment posture

HTTPS is enforced everywhere with sensible security headers
Production and development are separated, with no shared credentials between them

Risk reading

Tick what you know is true of your app.

ReadingNot ready for real data

Authentication and sessions: 2 of 2 open
AI-generated apps frequently ship interface-only gatekeeping: the page hides the button while the endpoint behind it answers to anyone.
Authorisation and object access: 2 of 2 open
Broken object-level authorisation is the most common serious finding in generated code: IDs in the URL, no ownership check behind them.
Secrets: 2 of 2 open
Assistants happily inline keys to make the demo work, and the demo becomes production. Client bundles and git history are where those keys get found.
Dependencies: 2 of 2 open
AI assistants suggest packages that are outdated, abandoned or occasionally do not exist, names attackers register in advance. Unpinned installs make it worse.
Input handling and injection: 2 of 2 open
Generated code handles the happy path. Injection lives in the paths nobody prompted for: the search box, the export, the webhook.
Data storage defaults: 2 of 2 open
Scaffolded storage tends to default open, and generated schemas hoard fields. Both problems are invisible until someone outside finds them.
Errors and information leakage: 2 of 2 open
Debug scaffolding that helped the assistant iterate leaks schema, paths and versions to anyone who triggers an error deliberately.
Deployment posture: 2 of 2 open
One-command deploys skip the boundary work: shared databases, shared keys, and a dev instance quietly reachable from the internet.

This reads your answers, not your code. A secure code review reads the code, confirms which of these are actually true, and demonstrates what an attacker gets from the ones that are not.

What this does, and what it deliberately does not.

This check covers the failure patterns that show up repeatedly in AI-assisted codebases. It reads your answers, not your code. A secure code review reads the code, exercises the findings, and proves what is exploitable.

Read alongside

Ready for someone to actually read the code?

Australia-wide, from our Brisbane head office. Someone will contact you as soon as possible.

Open a brief info@blackshard.com.au

AI-built app risk check.