You’ve built an app with a coding agent and are ready to share it or hand it to a client. A key in the browser or a missing permission check can expose data or let someone use features they shouldn’t. Use this checklist to find and fix common gaps before anyone depends on your app.
Start with secrets and access controls, then check input handling, request limits, dependencies, production settings, and backups. Ask your agent to audit the code, but verify its findings yourself. The OWASP Top 10 is a useful reference for web application security risks, including broken access control and security misconfiguration.
Keep private keys out of the app people download
Look for API keys, database passwords, signing keys, and other private credentials in the source files, repository history, frontend build output, and logs. A value shipped to the browser is available to the person using that browser, even if the interface never displays it.
Keep private credentials in server-side environment settings or a secrets manager, with access limited to the services that need them. Some providers issue keys intended to be public; check the provider’s documentation rather than assuming every key is safe to expose. OWASP’s secrets management guidance covers storage, access, rotation, and revocation.
If a private key has reached the repository or browser, treat it as exposed. Revoke or rotate it with the provider, update the server configuration, and remove the old value from the code and history where appropriate. Deleting a line from the latest version does not make an exposed credential unusable.
When asking the agent to inspect for secrets, tell it to report file locations and redact values. You need to know where the problem is, not receive another copy of the key.
Check permissions where the data is accessed
A hidden button does not prevent someone from making a request directly. The server must check the caller’s identity and permission for the action and the specific record. OWASP recommends trusted server-side access checks, denial by default, and tests for record ownership in its broken access control guidance.
Make a small access table before testing: which actions are public, which require an account, and which belong only to a record’s owner or an administrator? Compare that table with the server handlers. Check reads as well as edits and deletes.
Use test accounts and test data. Sign in as a regular user and try to request another test user’s record by changing its identifier. Repeat for edits and deletions. The request should fail unless your app deliberately allows that access. Also try the protected action while signed out.
Inspect database access rules separately. If your database supports row-level rules, verify that they restrict users to permitted records and that your application uses the intended role. Keep privileged database credentials on the server, and check that administrative access is only used where it is needed.
If you want an agent to run these tests for you, you can try the ZCode agent harness free with our invite link. The same checks apply whichever agent you use, and you still read the results yourself.
Validate requests and limit expensive actions
Browser validation helps people correct a form, but it can be bypassed. Validate requests on the server before using or storing them. OWASP’s input validation guide recommends checking types, required fields, allowed values, and size limits.
For a contact form, decide which fields are required, how long each may be, and what response an invalid submission receives. Send an empty field, an unexpected field, and an oversized value in your test environment. Confirm that invalid submissions are rejected and do not create records.
Validation is only one layer. Use parameterized database queries and check authorization separately: a correctly formatted record ID does not establish that the caller may view that record.
Add rate limits to sign-up, login, password recovery, and endpoints that trigger paid services or heavy processing. Set them for your app’s actual behavior and consider legitimate users who share a network. OWASP includes API rate limiting among its access-control recommendations.
Test that a normal request succeeds and that requests beyond your configured limit are rejected. Make the response clear enough for a legitimate user to retry later, without exposing internal details.
Inspect dependencies and production settings
Open the dependency manifest and lockfile, then identify what the agent added. For each new package, check the exact name against its official source, confirm it is the project you intended, and understand why your app needs it. Remove additions you do not use.
A familiar-looking package name is not a security review. Check the selected version and available security advisories, and note any dependency you cannot verify. OWASP’s software supply chain guidance recommends tracking components and obtaining them from trusted sources.
Next, review the deployed configuration. Turn off debug pages, development-only routes, and verbose errors in production. Trigger a controlled failure and check what a visitor sees. A useful error can say the action failed without revealing a stack trace, credentials, or private data; keep diagnostic details in protected server logs. See OWASP’s error handling guidance.
If you build like this every day, you can get a referral discount on GLM coding plans with our referral link; Z.ai's campaign terms give invited users a referral discount on their first GLM Coding subscription. Both Z.ai links in this post are our invite links, and we may receive referral credits.
Verify recovery, then use the checklist
A backup is useful only if you can find it and restore it. Identify what needs protection: database records, uploaded files, configuration, and any other data the app cannot recreate. Confirm who can access the backups and where recovery instructions live.
Restore a copy into a separate test environment. Check that the expected records and files are present and that you can sign in without exposing the restored data publicly. Record the steps and any gap you discover. Avoid testing recovery by overwriting your only live copy.
Before sharing the app, save this checklist:
- Private credentials stay out of frontend code, builds, logs, and the repository
- Exposed credentials are revoked or rotated
- Server checks identity and permission for protected actions and records
- Database rules restrict access to permitted records
- Server validates inputs and uses safe database queries
- Sign-up, login, recovery, and expensive endpoints have rate limits
- Added packages are the intended dependencies from trusted sources
- Production debug routes and verbose errors are disabled
- Backups are protected and a restore has been tested
An unchecked box is a release decision, not a detail to hide in the handoff. Tell the client what remains unverified and resolve the risk before real users or data depend on it.
Ask the agent to audit, then verify its work
Paste this prompt into your coding agent before the final review:
Audit this app against the checklist below. Do not change files.
Check private secrets in frontend code, builds, logs, repository
files, and history. Redact any suspected secret; do not print it.
Check server-side authentication and authorization for protected
actions and individual records. Review database access rules,
including row-level policies where supported.
Check server-side input validation, database query handling,
and rate limits for sign-up, login, recovery, and costly endpoints.
List every dependency added in this change. Give its exact name,
version, source, and purpose. Flag anything you cannot verify.
Check production debug settings, test routes, error responses,
backup configuration, and documented restore steps.
Return findings with file paths and line references where possible.
For each check, state the evidence inspected and label it verified,
failed, or needs human verification. Do not claim a check passed
if you could not access or test it.
Review the cited code, deployed settings, test results, and restore evidence yourself. If the agent cannot inspect a production setting, check it directly rather than accepting a guess. For more practical build notes, visit our blog.
Next, use WURK’s pre-launch QA checklist to review the rest of the app before handoff.
If this helped you prepare for release, a small tip on this post helps keep these guides coming.
Latest comments
0