AgentStack
Browse Sign in
Browse Why AgentStack Sell Docs
Sign in
SKILL verified MIT Self-run

Saas Code Security Review

skill-hlsitechio-claude-skills-security-saas-code-security-review · by hlsitechio

Application-code security review for SaaS backends focusing on authentication, authorization, IDOR/BOLA, SSRF, JWT handling, injection (SQL/NoSQL/command/template), deserialization, mass assignment, and SAST findings. Multi-stack (Node/TypeScript, Python, Go, Java, Ruby). Use this skill whenever the user asks to review code for security bugs, find IDOR or BOLA vulnerabilities, audit auth flows, c…

No reviews yet
0 installs
40 views
0.0% view→install

Install

$ agentstack add skill-hlsitechio-claude-skills-security-saas-code-security-review

✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

View the full security report →

Verified badge

Passed review? Show it. Paste this badge into your README, it links to the public security report.

AgentStack Verified badge Links to your public security report.
[![AgentStack Verified](https://agentstack.voostack.com/badges/verified.svg)](https://agentstack.voostack.com/security/report/skill-hlsitechio-claude-skills-security-saas-code-security-review)

Reliability & compatibility

Security review passed
0 installs to date
no reviews yet
4mo ago

Declared compatibility

Claude CodeClaude Desktop

Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.

Preview Execution monitoring

We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.

How agent discovery & health will work →
Are you the author of Saas Code Security Review? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

SaaS Code Security Review

Find application-layer vulnerabilities in SaaS backend code: authentication flows, authorization checks, request handling, and trust boundaries. Defensive (find & fix) focus.

When this skill applies

  • Reviewing source code (a PR diff, a specific file, or a directory) for security bugs
  • Interpreting and triaging SAST output (CodeQL, Semgrep, Snyk Code, Sonar)
  • Walking an auth flow looking for bypass paths
  • Checking JWT issuance and validation correctness
  • Hunting for IDOR / BOLA in REST or GraphQL endpoints

Use other skills for: backend RLS/database (supabase-security-audit), API surface concerns like rate limiting and CORS (saas-api-security), tenant-isolation focus (saas-tenant-isolation).

Workflow

Follow ../_shared/audit-workflow.md. Skill-specific notes below.

Phase 1: Scope confirmation

  • Language and framework (informs which patterns to look for)
  • Auth model (sessions? JWT? both?)
  • Database tech (informs injection patterns)
  • Whether this is a PR review (smaller scope, recent diff) or a directory audit (broader)

Phase 2: Inventory

  • Identify entry points: HTTP route handlers, GraphQL resolvers, gRPC services, message queue consumers, CLI commands, scheduled jobs.
  • Identify trust boundaries: where user input enters, where it crosses to the database, where it leaves to other services.
  • Identify auth/authz code: middleware, decorators, policy functions, RBAC tables.
  • Note any auto-generated boilerplate (often skipped in human review, sometimes vulnerable).

Phase 3: Detection — the categories

Categories below are not exhaustive but cover the high-value classes for SaaS backends.

Authentication
  • SCSR-AUTH-1 Password storage uses Argon2id (preferred) or bcrypt with cost ≥ 12. No SHA-256, MD5, or PBKDF2-SHA1 with low iteration counts.
  • SCSR-AUTH-2 Authentication endpoints are rate-limited per-account and per-IP independently.
  • SCSR-AUTH-3 No user enumeration via response timing, status code, or message ("user not found" vs "wrong password" reveals which).
  • SCSR-AUTH-4 Account lockout or progressive delay after N failed attempts, with safe lockout reset.
  • SCSR-AUTH-5 Password reset tokens are single-use, time-limited (≤ 1 hour), and invalidated on use.
  • SCSR-AUTH-6 Email change requires confirmation at both old and new addresses.
  • SCSR-AUTH-7 Session fixation prevented: regenerate session ID on login.
Authorization — see references/idor-bola-patterns.md

This is the most common SaaS vulnerability class. Every endpoint that takes an ID parameter needs an authorization check.

  • SCSR-AZ-1 Every endpoint that accepts a resource ID checks the requester owns/has-access-to that resource before returning it.
  • SCSR-AZ-2 Authorization checks happen in the data-access layer, not just the route handler (defense in depth).
  • SCSR-AZ-3 Bulk endpoints (list, search, batch update) filter by tenant/owner in the database query, not after the fact in memory.
  • SCSR-AZ-4 GraphQL resolvers check authorization on each field that exposes another user's data, not just the root.
  • SCSR-AZ-5 Admin actions verify the requester's admin role AND that the target is within the admin's scope (an org admin can't modify another org).
  • SCSR-AZ-6 Indirect references (UUIDs, sequential IDs) don't bypass the check — the check is on the relationship, not on the unguessability.
JWT handling — see references/jwt-validation.md
  • SCSR-JWT-1 Algorithm is allowlisted to a specific value, never alg: none or alg taken from the token.
  • SCSR-JWT-2 Signature verification happens before any claim is read.
  • SCSR-JWT-3 iss, aud, and exp validated; nbf if used.
  • SCSR-JWT-4 Key rotation supported via kid; old keys revoked.
  • SCSR-JWT-5 No JWT used as session token for high-value flows without server-side revocation (use opaque session IDs in Redis instead, or pair JWT with revocation list).
  • SCSR-JWT-6 Secrets are random, ≥ 256 bits for HMAC; never reused across services.
  • SCSR-JWT-7 Refresh tokens are rotated on use; reuse triggers a revocation cascade.
Injection
  • SCSR-INJ-SQL SQL queries use parameterized statements; no string concatenation with user input.
  • SCSR-INJ-NOSQL MongoDB queries don't accept operator-shaped objects from user input ({$ne: null} attack). Sanitize or use strict schema validation.
  • SCSR-INJ-CMD No exec/spawn/system with user-controlled arguments. If shelling out is needed, use array form (not shell string) and validate.
  • SCSR-INJ-TMPL Template engines (Jinja, ERB, Handlebars with helpers) don't render user input as template, only as data.
  • SCSR-INJ-LDAP LDAP filters escape user input; no string concat into filter expressions.
  • SCSR-INJ-XPATH Same as LDAP, applied to XPath.
SSRF — see references/ssrf-patterns.md
  • SCSR-SSRF-1 Outbound HTTP fetches from user-supplied URLs use an allowlist OR a DNS resolver that blocks RFC1918, link-local, and cloud metadata IPs.
  • SCSR-SSRF-2 Redirects followed only if the redirect target also passes the allowlist (re-validate each hop).
  • SCSR-SSRF-3 Webhooks and image fetches both apply the protection — not just user-facing "make request" endpoints.
  • SCSR-SSRF-4 Cloud metadata endpoint (169.254.169.254, AWS IMDSv1) blocked at the network or HTTP layer.
Mass assignment / parameter binding
  • SCSR-MA-1 Frameworks that auto-bind request body to model objects (Rails, Spring, ASP.NET, NestJS class-transformer) explicitly allow-list assignable fields.
  • SCSR-MA-2 Admin-only fields (isAdmin, role, tenant_id, verified) never assignable from user-controlled input.
  • SCSR-MA-3 GraphQL inputs use specific input types, not the same object as the read model.
Deserialization
  • SCSR-DESER-1 No pickle.load, yaml.load (without SafeLoader), unserialize (PHP), or Java native deserialization on untrusted bytes.
  • SCSR-DESER-2 JSON parsers configured to reject unknown fields or prototype-pollution-shaped keys.
Cryptography
  • SCSR-CRY-1 No homegrown crypto. Use platform primitives (AES-GCM, ChaCha20-Poly1305, X25519, Ed25519).
  • SCSR-CRY-2 Random values from a CSPRNG (crypto.randomBytes, secrets.token_bytes, crypto/rand), never Math.random / random.randint.
  • SCSR-CRY-3 Timing-safe comparison for secrets (token equality, MAC verification).
  • SCSR-CRY-4 No ECB mode. No CBC without HMAC-then-encrypt.
File and upload handling
  • SCSR-FILE-1 Uploaded filenames sanitized (path traversal, null bytes).
  • SCSR-FILE-2 Content type validated by magic-byte inspection, not just Content-Type header.
  • SCSR-FILE-3 Storage path doesn't combine user-provided segments with os.path.join-like calls without validation.
  • SCSR-FILE-4 Image processing libraries (ImageMagick, sharp) running on uploads have CVE patches applied.
  • SCSR-FILE-5 Served from a separate origin or with Content-Disposition: attachment to prevent XSS-via-upload.
Error handling and information disclosure
  • SCSR-ERR-1 Stack traces never returned to the client in production.
  • SCSR-ERR-2 Error messages distinguish user-facing (safe) from log-only (full detail).
  • SCSR-ERR-3 Debug endpoints (e.g., /debug, /__debug__, /_status) gated by auth or removed from production builds.

Phase 4: Triage

Critical class examples:

  • Auth bypass via missing check on any state-changing endpoint
  • SQL injection on any endpoint
  • SSRF reaching cloud metadata
  • IDOR returning another tenant's data
  • RCE via deserialization, template injection, or command injection

Phase 5: Report

Use ../_shared/findings-schema.md. Prefix IDs with SCSR-. For each finding, include the file path and line number, plus a 2-3 line patch where feasible.

Output style

  • For PR-scoped reviews, structure the report by file rather than by severity (matches how the developer reads the diff).
  • For directory audits, structure by severity then category.

References

  • references/idor-bola-patterns.md — Authorization patterns across REST, GraphQL, batch endpoints
  • references/jwt-validation.md — Common JWT bugs with example fixes per language
  • references/ssrf-patterns.md — Allowlists, DNS rebinding, cloud metadata protection
  • references/sast-triage.md — How to read CodeQL/Semgrep/Snyk output and prioritize

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet, be the first.

Versions

  • v0.1.0 Imported from the upstream source.