> ## Content Index > Fetch the complete content index at: https://theseguysknow.io/llms.txt > Use this file to discover other available public pages before exploring further. # App Security Check: Before Launch, Ask Claude These Questions - URL: https://theseguysknow.io/claude-code-security-checklist-before-launch/ - Published: 2026-08-17T13:50:32.000Z - Updated: 2026-08-17T13:58:30.000Z - Description: A working app is not necessarily a safe app. These 20 questions help Claude find serious security mistakes, reproduce them and prove whether the fixes work. - Author: Mike Hazard - Tags: AI & Tech, AI Tools & Models A finished-looking app can still have a completely open back door. The login works, the dashboard loads and the payment button takes money, yet another user may be able to read private records by changing one ID in a request. A secret may already be sitting inside the browser bundle. The admin button may be hidden while the admin endpoint remains public. This is where Claude can help. It can trace access controls, inspect database policies, find exposed credentials and write tests much faster than most people can do the same review manually. The mistake is asking, “Is my app secure?” and accepting a long answer that ends with a green tick. Make Claude show its work. For every serious finding, it should explain how the failure can be reproduced, patch the code and run the same test again. If the first test never existed, “fixed” means very little. ## Quick answer Before launching an app, have Claude check **database access rules, exposed secrets, server-side authentication, object-level authorization, API responses, query safety, input validation, user-generated content, file uploads, sessions and cookies, password handling, rate limits, bot protection, security headers, HTTPS, dependency vulnerabilities, Git history and leaked credentials.** For anything high-risk, reproduce the problem first, apply the fix, then repeat the same test. The issue is only fixed when the unauthorized action fails and the legitimate one still works. Claude can help find and fix security problems, but it cannot certify an app as secure. Use it alongside secret scanning, dependency scanning, runtime testing, backups and human review. ## Why a working app tells you almost nothing about security AI coding tools are very good at getting a product into a browser. Security failures often sit behind that visible layer, where the app decides which user may read a record, change a price, call an admin function or download a file. The consequences are no longer theoretical. Wiz found a misconfigured Supabase database behind Moltbook that allowed unauthenticated read and write access. The exposure included 1.5 million authentication tokens, 35,000 email addresses and private agent messages. The public Supabase key was not the vulnerability by itself. The database behind it lacked the required Row Level Security policies. [Wiz documented the incident and its verification process](https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys?ref=theseguysknow.io). Escape later reported more than 2,000 high-impact vulnerabilities, over 400 exposed secrets and 175 instances of exposed personal information after examining 5,600 publicly available apps built with AI-assisted platforms. Its researchers used passive testing and kept only findings they could verify with high confidence. [The company published its methodology](https://escape.tech/blog/methodology-how-we-discovered-vulnerabilities-apps-built-with-vibe-coding/?ref=theseguysknow.io), which matters more than a frightening headline with no explanation behind it. Veracode reached a similar conclusion from a different direction. In its 2026 code-generation research, only 55% of tasks produced secure code, meaning 45% introduced a known security flaw. That does not make every AI-generated function dangerous. It means functional output cannot be treated as evidence of safe output. [Veracode published the updated results here](https://www.veracode.com/blog/spring-2026-genai-code-security/?ref=theseguysknow.io). ## Give Claude rules before asking it to inspect anything Run active tests only against an app you own or are authorised to test. Anything that writes, deletes, uploads or triggers payments belongs in a local or staging environment with disposable accounts and test data. Start with this instruction before using the individual prompts below: ``` Act as a defensive application-security reviewer for this repository. Start in read-only mode. Do not edit files, rotate credentials, access production data, send external requests or run destructive commands without my explicit approval. First identify the stack, trust boundaries, user roles, data stores, authentication system, privileged actions, external services and deployment configuration. Then review the requested area. For every finding, provide: 1. Severity and realistic impact. 2. The exact file, function, route, policy or configuration involved. 3. The conditions required to exploit it. 4. A safe local or staging test that proves whether the problem exists. 5. The smallest reasonable fix. 6. The same test to run after the fix. Separate confirmed vulnerabilities from suspicions and missing information. Do not call an issue fixed until the original test fails safely and the intended user flow still passes. ``` This framing prevents Claude from rushing straight into edits. You want a map of the problem before it starts moving code around. ## 1\. Can one user read or change another user’s data? This is the first launch blocker. Create two ordinary test accounts. User A should be unable to read, update or delete User B’s orders, messages, files, profile details or subscription records, even after changing IDs in a request. If the app uses Supabase, inspect every table, view, RPC function and storage bucket exposed through the API. Tables created in the Supabase dashboard may have RLS enabled automatically, while tables created through raw SQL or migrations still require an explicit check. A policy existing is not enough; it must enforce the correct owner or tenant boundary. ### Prompt Claude ``` Map every table, API route, RPC function and storage bucket containing user or tenant data. For each one, identify how the server or database decides which records the current user may read, create, update and delete. Create a test matrix covering: - unauthenticated visitor - User A accessing User A data - User A accessing User B data - admin access Do not change the code yet. Show the exact authorization rule and write safe staging tests that should prove cross-user access is denied. ``` ### Prove the fix Run User A’s valid request, replace only the object or owner ID with User B’s value and repeat it. The second request should return a denial or no records. Repeat the same check for reads, updates and deletes; a read policy says nothing about the write policy. ## 2\. Can a logged-out visitor reach private or administrative endpoints? Hiding a page or button is presentation, not access control. A visitor can call the underlying route without using your interface. Every private API, server action and administrative function needs its own server-side check. ### Prompt Claude ``` List every route, server action, API handler, RPC function and background-job trigger that returns private data or performs a privileged action. Trace the authentication and authorization check for each one. Flag anything protected only by client-side routing, a hidden component, a disabled button or a role value stored in browser state. Write unauthenticated staging tests for every high-risk endpoint. Do not patch anything until the tests show the current behaviour. ``` ### Prove the fix Call the endpoint without cookies, tokens or browser state. Then try again with an ordinary account. Private routes should reject the first request, while administrative routes should reject both. ## 3\. Does every sensitive action check permission on the server? Being logged in answers who the user is. It does not answer what that user may do. An authenticated customer should not be able to refund another order, change another account, approve an invoice or call an internal moderation action. ### Prompt Claude ``` Review every endpoint and server action that changes money, ownership, roles, permissions, subscriptions, account state or other users' data. For each action, show where the server verifies both the current identity and permission for the specific target object. Flag checks that only confirm the user is logged in. Create tests for an ordinary user attempting the same action on their own object, another user's object and an admin-only object. ``` ### Prove the fix Keep the session valid and change only the target object. The authorised request should succeed. The same request against another user’s object should return `403`, `404` or the equivalent denial without changing anything. ## 4\. Is the app trusting roles or permissions supplied by the browser? Client-side values can be edited. A role stored in local storage, a hidden `isAdmin` field or a request containing `plan: enterprise` is merely user input until the server verifies it against trusted data. ### Prompt Claude ``` Find every place where roles, permissions, subscription tiers or feature access are read from client state, request bodies, URL parameters, local storage or unsigned tokens. Trace each value to the server-side source of truth. Flag any privileged decision based on a value the browser can change. Write a staging test that tampers with each untrusted role or plan value and proves the server ignores or rejects it. ``` ### Prove the fix Change the client-supplied role or subscription value and repeat the request. Nothing privileged should happen unless the server independently confirms that permission from its own trusted record. ## 5\. Has any privileged secret reached the browser? Search the built application, not only the source `.env` file. Modern build tools copy selected environment variables into JavaScript bundles, and changing the variable name after deployment does not remove the old bundle from every cache. Supabase needs a precise distinction here. Its `sb_publishable_...` key, along with the legacy `anon` key, is designed for public clients when database policies are correct. The `sb_secret_...` key and legacy `service_role` key are privileged, bypass RLS and must remain on a trusted server. [Supabase documents the difference directly](https://supabase.com/docs/guides/getting-started/api-keys?ref=theseguysknow.io). ### Prompt Claude ``` Search the source, generated build output, public assets and client-side network requests for credentials, private keys, connection strings and privileged tokens. Classify every result as public configuration, publishable client key or confidential server credential. For Supabase, distinguish publishable/anon keys from secret/service_role keys and inspect the RLS configuration before calling a public key a vulnerability. Redact all credential values in your report. Show only the type, location, exposure path and required response. ``` ### Prove the fix Build the production bundle again and search the generated files. Inspect browser network requests and page source. A privileged value must be absent everywhere the client can receive. ## 6\. Has a secret been committed, logged or pasted somewhere else? Removing a leaked credential from the current file does not make it private again. Copies can remain in Git history, CI logs, deployment previews, support tickets and AI chat histories. The order matters: revoke or rotate the credential first, remove every exposed copy second, review its use during the exposure window and then add scanning to prevent the same mistake. ### Prompt Claude ``` Perform a read-only secret exposure review across the current tree, Git history, example files, logs, CI configuration and deployment files. Use an established secret scanner where available rather than relying only on text search. Do not print secret values. Report the credential type, first known commit or location, whether it appears in current code and whether rotation is required. If a live credential is found, stop and give me an ordered containment plan beginning with revocation or rotation. Do not rewrite Git history until I approve the exact scope. ``` ### Prove the fix Confirm the old credential fails, the replacement works only from its intended environment and a fresh secret scan no longer finds an active value. Rewriting history without rotation is cosmetic. ## 7\. Can a user change fields the server should control? An update endpoint may accept an entire object because it was convenient during development. That becomes a serious problem when the same object contains `user_id`, `price`, `payment_status`, `role`, `approved` or `is_admin`. ### Prompt Claude ``` Review create and update handlers for mass assignment. Identify fields copied directly from request bodies into database writes, ORM models or service calls. Mark fields that must be controlled by the server, including owner IDs, roles, prices, discounts, payment status, approval state and internal timestamps. Create tests that add or modify these protected fields from an ordinary user request. Recommend explicit allowlists for accepted input. ``` ### Prove the fix Send a valid request with one extra protected field. The intended edit may succeed, but the protected value must remain unchanged. Test each privileged field individually so one rejection does not hide another gap. ## 8\. Can user input reach a database, shell or template as executable code? Validation in the interface is easy to bypass. The important question is how untrusted values are handled when they reach database queries, command execution, templates and dynamic code paths. ### Prompt Claude ``` Trace all untrusted input from requests, forms, URL parameters, headers, uploaded metadata and external webhooks into database queries, shell commands, template rendering, dynamic imports and evaluation functions. Flag string-built queries or commands and any use of eval-like behaviour. Show where parameterised queries, safe APIs or strict allowlists are already used. Write non-destructive tests using harmless payloads that demonstrate whether input changes query or command structure. Do not execute operating-system commands or touch production services. ``` ### Prove the fix The harmless test input should be treated as data, not syntax. Confirm the legitimate request still works after replacing string construction with parameters or a strict allowlist. ## 9\. Can user-controlled content execute in another person’s browser? Comments, profile names, filenames, Markdown, rich text and imported HTML can all become stored cross-site scripting if the app renders them unsafely. Escaping at input time alone is unreliable because the correct treatment depends on where the value is later inserted. ### Prompt Claude ``` Find every place user-controlled or externally sourced content is rendered into HTML, attributes, URLs, CSS, Markdown or client-side scripts. Identify unsafe HTML insertion, incomplete sanitisation and contexts where ordinary escaping is insufficient. Include stored content as well as reflected URL or form values. Create a harmless staging test string for each rendering context and show the expected safe output. Do not use payloads that steal data or contact external systems. ``` ### Prove the fix Save the harmless test content through the normal application flow and view it from a second account. It should appear as text or permitted markup without executing, redirecting or changing the page. ## 10\. Can an uploaded file become executable or publicly expose private data? Checking the filename extension in the browser is weak protection. The server needs limits for file type, size, naming, storage location and access. Private uploads should not become permanent public URLs unless that is the intended product behaviour. ### Prompt Claude ``` Review every file-upload path from browser to storage and later download or rendering. Check server-side size limits, content-type verification, extension allowlists, generated filenames, storage permissions, malware scanning where appropriate and whether uploaded files can execute or be rendered as active content. Map which uploads should be public, private or temporary. Write safe tests for an oversized file, a mismatched extension and content type, and one user requesting another user's private file. ``` ### Prove the fix A valid file should upload and remain available to the authorised user. The oversized, disguised or cross-user requests should fail before the file becomes accessible. ## 11\. Can the server be tricked into fetching an unsafe URL? URL previews, webhooks, image importers, PDF generators and “import from link” features can make requests on the server’s behalf. Without restrictions, that feature may reach internal services, cloud metadata endpoints or local addresses that outside users cannot access directly. ### Prompt Claude ``` Find every feature where user-controlled input causes the server, worker or browser automation to fetch a URL. Review protocol restrictions, hostname and IP validation, redirect handling, DNS resolution, timeouts, response-size limits and blocks for loopback, private, link-local and cloud-metadata addresses. Create safe local tests proving that approved public URLs work while local and private-network destinations are rejected, including after redirects. ``` ### Prove the fix Test an allowed public URL and a controlled local address. The second request should be rejected before a connection is made, including when a permitted-looking URL redirects to it. ## 12\. Are incoming webhooks authenticated and safe to replay? A webhook route is public by design, so hiding its URL provides little protection. The receiver should verify the provider’s signature against the raw request body, reject stale timestamps and handle repeated deliveries without applying the same payment or action twice. ### Prompt Claude ``` Review every webhook receiver. Identify how it verifies the provider signature, timestamp and expected event source before parsing or processing the event. Check replay protection, duplicate-event handling, idempotency, ordering assumptions and whether failed events can be retried safely. Write staging tests for a valid signed event, an invalid signature, a stale event and the same valid event delivered twice. ``` ### Prove the fix The valid event should run once. The invalid and stale events should be rejected, while the duplicate should be acknowledged without repeating the business action. ## 13\. Are sessions and cookies handled correctly? Sessions need more than a working login. Check where tokens live, which JavaScript can read them, whether cookies use suitable `HttpOnly`, `Secure` and `SameSite` settings, and whether logout, password changes and account suspension invalidate old access. ### Prompt Claude ``` Trace the complete session lifecycle: login, token creation, client storage, renewal, expiration, logout, password change, privilege change and account suspension. Review cookie flags, token exposure to client-side JavaScript, session fixation, refresh-token rotation and server-side invalidation. Create staging tests proving an expired, logged-out or revoked session can no longer access private routes while a current session still works. ``` ### Prove the fix Copy a test session, log out or revoke it, then retry a private request with the old value. A successful interface logout is irrelevant if the old session still works against the server. ## 14\. Can someone abuse registration, login or account recovery? Password reset and magic-link flows often receive less attention than login, despite being another route into the same account. Look for reusable reset links, long expiration windows, user enumeration and a change of email or password that does not require suitable verification. ### Prompt Claude ``` Review registration, login, email verification, password reset, magic-link, email-change and account-recovery flows. Check token entropy, expiry, one-time use, redirect validation, session invalidation and whether responses reveal if an email address is registered. Write staging tests for an expired token, a reused token, an altered redirect and requests for existing versus unknown accounts. ``` ### Prove the fix A valid recovery link should work once. Reuse, expiry and altered destinations should fail, while the public response should not provide a reliable list of registered email addresses. ## 15\. What can be abused without a rate limit or spending limit? Login attempts are the obvious target, but expensive AI calls, email sending, account creation, search, exports and file processing can cause larger bills or knock the app over. ### Prompt Claude ``` List public and authenticated actions that can be automated for credential attacks, spam, scraping, resource exhaustion or direct third-party cost. Review rate limits by IP, account, device or API key, along with quotas, concurrency limits and hard spending controls. Do not recommend one generic limit for every route. Create a staging test showing the normal request volume succeeds, the abusive burst is throttled and one noisy user does not block every legitimate user. ``` ### Prove the fix Exceed the chosen staging limit with a disposable account. Confirm the server slows or rejects further requests, records the event and recovers after the intended window without charging for work it refused. ## 16\. Are CORS and CSRF protections matched to the way the app authenticates? CORS decides which browser origins may read responses. It does not replace authentication. CSRF matters when browsers automatically attach credentials such as cookies. Copying a permissive development configuration into production can expose sensitive actions to another site. ### Prompt Claude ``` Review the production CORS policy and every state-changing request that relies on cookies or other automatically attached browser credentials. List allowed origins, methods, headers and credential settings. Flag wildcard or reflected origins where private responses are involved. For cookie-authenticated actions, review SameSite settings, CSRF tokens and Origin or Referer validation. Write tests from an allowed origin and a disallowed origin without weakening authentication. ``` ### Prove the fix The real frontend should continue to work. A request initiated from an unapproved origin should be unable to read private data or perform a state-changing action with the victim’s session. ## 17\. Do errors and logs reveal secrets or personal information? Detailed stack traces are useful during development and terrible as public error pages. Logs can quietly collect passwords, access tokens, reset links, full payment payloads and private prompts long after the original request has disappeared. ### Prompt Claude ``` Review production error handling, application logs, analytics events, audit logs and third-party monitoring payloads. Search for passwords, session tokens, API keys, authorisation headers, reset links, payment data, private prompts and unnecessary personal information. Check whether sensitive values are redacted before leaving the application. Create safe tests that trigger representative errors and confirm the user receives a generic response while the internal log contains useful context without confidential values. ``` ### Prove the fix Trigger the same error in staging and inspect both the response and collected log. The user should not see implementation details, and the log should identify the event without storing the secret used to reproduce it. ## 18\. Did development-only files, routes or settings reach production? Debug endpoints, test accounts, source maps, sample data, open API documentation and forgotten admin tools can expose more than the main application. Deployment configuration deserves its own review because the repository may be safe while the shipped result is not. ### Prompt Claude ``` Compare development, staging and production configuration. Find debug routes, test credentials, sample users, verbose errors, public source maps, directory listings, development proxies, open database consoles and internal documentation exposed by the production build. Inspect the generated deployment artefact and infrastructure configuration, not only source files. Classify each finding as intentional public information or unintended exposure. Write a production-like staging check for every item that should be absent or access-controlled. ``` ### Prove the fix Build the same artefact intended for production and inspect it from outside the trusted network. A local configuration file saying `debug: false` is not proof that the deployed route disappeared. ## 19\. Are dependencies and automated build steps trustworthy? Claude may write safe application code while installing a package with a known vulnerability or a malicious lookalike name. Build scripts and third-party Claude skills deserve the same suspicion because they can read files, execute commands and contact external systems. ### Prompt Claude ``` Review direct and transitive dependencies, lockfiles, install scripts, GitHub Actions, build hooks and third-party Claude skills or MCP servers used by this project. Run the ecosystem's established vulnerability audit and identify unpinned actions, unexpected package names, abandoned dependencies and scripts with filesystem, credential or network access. Verify package and repository ownership from authoritative sources before recommending installation. Do not install or execute a new security tool during this review without my approval. ``` ### Prove the fix Run the clean build from a fresh environment with the lockfile enforced. The dependency scan should no longer report the addressed high-risk issue, and every retained automation step should have a clear owner and reason for its permissions. ## 20\. If the app uses AI, can user content control tools or expose private context? An AI feature becomes more serious when it can read private files, query customer data, browse internal systems, send messages or make purchases. A prompt saying “ignore your previous instructions” is only one part of the problem. The real question is whether untrusted content can cause a privileged action without a separate policy check. ### Prompt Claude ``` Map every AI feature, the data placed in its context, the tools it can call and the permissions attached to those tools. Identify where untrusted user, webpage, document, email or retrieved content can influence tool selection or arguments. Check tenant separation, data minimisation, output handling and confirmation requirements for consequential actions. Create safe staging tests using clearly marked instruction-like content. Prove the model cannot reveal another user's context, access a tool beyond the current user's permission or perform a consequential action without server-side approval. ``` ### Prove the fix The model may still repeat or discuss hostile text. That is different from obeying it. The important result is that the server refuses unauthorised data access and tool calls regardless of what the model produces. ## Run Claude Code’s security review last [Claude Code ](https://theseguysknow.io/5-best-claude-code-plugins-and-tools-in-2026/)includes a built-in `/security-review` command for pending changes. Anthropic also publishes a GitHub Action that reviews pull-request diffs and reports high-confidence findings. Both are useful final nets after the targeted checks above. Neither should be presented as a complete inspection of the running application. Run: ``` /security-review ``` Then follow with: ``` For every high-severity finding in this review, separate confirmed issues from hypotheses. Show the exact evidence, write a safe test that reproduces the current behaviour, and explain what the test must return after the fix. Do not edit anything until I approve the test plan. ``` Anthropic says the GitHub Action analyzes changed files in pull requests, and it warns that the action is not hardened against prompt injection. External pull requests should therefore require maintainer approval before the workflow receives access to a Claude API key. [Those limitations appear in Anthropic’s own repository](https://github.com/anthropics/claude-code-security-review?ref=theseguysknow.io). Anthropic also publishes a more advanced defending-code reference harness with a recon, discovery, verification and patching pipeline. It is not a plug-and-play scanner for an ordinary web app. The repository is unmaintained, its supplied autonomous harness is configured around C and C++ memory vulnerabilities, and code execution requires proper sandboxing. [Anthropic calls it a reference implementation rather than a product](https://github.com/anthropics/defending-code-reference-harness?ref=theseguysknow.io). ## The final launch sequence Once Claude has finished talking, the application still needs to pass a short sequence of real checks: 1. Test tenant isolation with two ordinary accounts and one administrator. 2. Rotate every privileged credential that reached an untrusted location. 3. Rebuild and scan the production artefact for secrets and development files. 4. Run dependency, secret and runtime scanners appropriate to the stack. 5. Repeat every confirmed exploit after its patch. 6. Confirm legitimate users can still complete the affected action. 7. Restore a staging copy from backup instead of merely checking that a backup file exists. 8. Confirm security events, failed logins and privileged actions produce usable alerts. If the application handles payments, medical information, identity documents or valuable private data, bring in a competent security specialist before opening it to the public. Claude can make the review faster and expose mistakes that would otherwise survive launch. It cannot accept responsibility for what it misses. ## Final verdict Ask Claude all 20 questions, but judge the answers by what you can reproduce. The best result is not a long security report or a clean score. It is a collection of tests showing that the dangerous action worked before the patch, fails after it and has not broken the correct path for a legitimate user. Your app works. Good. Now make it prove that one customer cannot become another customer, an ordinary user cannot become an administrator and a public browser cannot become your backend. --- #### Sources - [Wiz Research — Hacking Moltbook: The AI Social Network Any Human Can Control](https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys?ref=theseguysknow.io) - [Escape — Methodology: How We Discovered Over 2k High-Impact Vulnerabilities in Apps Built With Vibe Coding Platforms](https://escape.tech/blog/methodology-how-we-discovered-vulnerabilities-apps-built-with-vibe-coding/?ref=theseguysknow.io) - [Veracode — Spring 2026 GenAI Code Security Update](https://www.veracode.com/blog/spring-2026-genai-code-security/?ref=theseguysknow.io) Claude and Anthropic security tooling - [Anthropic — Claude Code Security Reviewer](https://github.com/anthropics/claude-code-security-review?ref=theseguysknow.io) - [Anthropic — Defending Code Reference Harness](https://github.com/anthropics/defending-code-reference-harness?ref=theseguysknow.io) Supabase security - [Supabase — Understanding API Keys](https://supabase.com/docs/guides/getting-started/api-keys?ref=theseguysknow.io) - [Supabase — Row Level Security](https://supabase.com/docs/guides/database/postgres/row-level-security?ref=theseguysknow.io) - [Supabase — Securing Your API](https://supabase.com/docs/guides/api/securing-your-api?ref=theseguysknow.io) Application-security guidance - [OWASP — Top 10:2025](https://owasp.org/Top10/?ref=theseguysknow.io) - [OWASP — API Security Top 10:2023](https://owasp.org/API-Security/editions/2023/en/0x11-t10/?ref=theseguysknow.io) - [OWASP — Broken Object Level Authorization](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/?ref=theseguysknow.io) - [OWASP — Broken Object Property Level Authorization](https://owasp.org/API-Security/editions/2023/en/0xa3-broken-object-property-level-authorization/?ref=theseguysknow.io) - [OWASP — File Upload Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/File%5FUpload%5FCheat%5FSheet.html?ref=theseguysknow.io) - [OWASP — Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session%5FManagement%5FCheat%5FSheet.html?ref=theseguysknow.io) - [OWASP — Cross-Site Request Forgery Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site%5FRequest%5FForgery%5FPrevention%5FCheat%5FSheet.html?ref=theseguysknow.io) - [OWASP GenAI Security Project — Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/?ref=theseguysknow.io) Secrets, dependencies and transport - [GitHub Docs — Push Protection From the Command Line](https://docs.github.com/en/code-security/concepts/secret-security/command-line-push-protection?ref=theseguysknow.io) - [GitHub Docs — Dependabot Malware Alerts](https://docs.github.com/en/code-security/concepts/supply-chain-security/malware-alerts?ref=theseguysknow.io) - [MDN — Set-Cookie Header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie?ref=theseguysknow.io) - [MDN — Transport Layer Security and HSTS](https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Transport%5FLayer%5FSecurity?ref=theseguysknow.io)