Secure Your Code with Automated Security Reviews

Security Review guides examination of application security practices and potential vulnerabilities. It covers secrets, input and upload validation, database queries, authentication and authorization, browser defenses, rate limits, sensitive data exposure, dependency handling and selected Solana wallet concerns. A checklist organizes review work but cannot establish that all code is secure.

Use the detailed guide as a required companion, loading relevant sections for focused work and the complete procedure for end-to-end review. Its safety, prerequisites and validation requirements remain part of the workflow. The inline material provides example checks and code sketches, rather than evidence that the target application already implements them correctly.

Use it when adding authentication, processing user input, exposing APIs, handling credentials, implementing payments, storing sensitive information or integrating external services. Match the review to the actual application and authorized scope. Missing permissions, inputs or success criteria must be resolved before affected execution steps.

Do not equate a clean dependency audit, a configured header or a passing illustrative test with complete security. Review context, preserve accepted findings and verify actual behavior. Dependency fixes and codemods belong on a reviewed branch with pinned versions and validation, rather than blind updates.

Inputs include the relevant implementation, session and permission model, data flows, upload paths, browser behavior, dependency lockfiles and available test environment. Outputs are specific findings, proposed corrections and evidence from the applicable checks. No test, configuration or deployment success should be implied without running and inspecting the relevant validation.

Secrets review checks configuration and hosting storage, ignored local files, repository history and logs. Do not hardcode credentials or expose tokens, passwords, payment details or stack traces. User-facing errors should be generic, while server-side diagnostic detail must still be reviewed for sensitive content rather than logged indiscriminately.

Input schemas validate permitted fields, types and ranges before processing. Parameterized queries or correctly used query builders keep user data out of SQL syntax. Upload size, browser MIME type and filename-extension checks are only usability filters: enforce server-side byte limits, inspect or decode content and use safe storage names and origins.

Authorization must derive requester identity from a verified server session, not a caller-supplied requesterId. Check permissions before sensitive operations and review database row policies in the actual role context. A JWT or a successfully authenticated user does not by itself prove authorization to another user's resource.

Cookie patterns use HttpOnly, Secure and an appropriate SameSite policy, with a serializer and deliberate Path and Domain. HttpOnly reduces direct token access but does not stop an XSS payload from issuing requests. Test OAuth redirects and CSRF behavior, using a vetted synchronizer-token or signed session-bound double-submit pattern where required.

HTML handling uses sanitization and safe rendering. Content Security Policy needs real framework header wiring and per-response nonces or hashes appropriate to the application, rather than copying permissive inline-script or evaluation settings. Framework escaping does not make every dynamic rendering path safe.

Rate controls cover authenticated users and network identity, with stricter limits for expensive operations. Example timing and request counts are illustrative; exercise them only with bounded authorized fixtures. Authentication, authorization, invalid-input and rate-limit tests are separate checks, each needing a representative setup and expected response.

Wallet ownership verification uses cryptographic signatures, but login also needs a server-issued single-use nonce bound to domain, purpose and expiry and consumed atomically. Signature validity alone allows replay. The transaction-intent sketch checks application-level recipient, amount and balance; it does not decode real Solana instructions, programs, fees, token mints or confirmation, and cannot justify blind signing.

Dependency review includes lockfiles, reproducible CI installation, vulnerability findings and update automation. One exact audit command is:

npm audit

Its result must be assessed alongside exploitability, application context and accepted residual findings. An audit-clean dependency tree is one signal rather than a certificate of application security.

This skill suits application developers and reviewers who can inspect the relevant implementation and validate fixes in a controlled environment. Its examples touch TypeScript, Express, Next.js, Supabase and Solana tooling; they must be adapted to installed versions and actual security boundaries.