Executive Summary

Riverbank Security provides on-demand, compliance-ready penetration testing with clear findings and practical remediation steps. We blend automation at scale with expert manual analysis to cover modern attack surfaces and simulate realistic threats. Our engagements include unlimited retesting, and are delivered by a US-based team. We align to OWASP Top 10, ASVS, PTES, and NIST SP 800-115 so your output maps cleanly to SOC 2, ISO 27001, HIPAA, and PCI-DSS expectations.

Our methodology is structured for coverage, speed, and auditability. Each phase produces concrete artifacts that flow into the final report and retest.

‍

Phase 1: Planning & Scoping

In this phase we ensure we’re testing the right things in the right way. We’ll agree on the systems in scope, how we’ll access them, and any safety rails you want in place.

We start with a brief scoping questionnaire and a kickoff call. You’ll share the primary URLs, a short description of the application, and how users log in (for example, username/password, SSO such as SAML or OIDC, and whether MFA is used). If your web app talks to APIs, sharing Swagger/OpenAPI or a Postman collection helps us test those endpoints accurately. We’ll also ask about third-party services (e.g., Auth0, Stripe, Firebase) so we understand where your application ends and a vendor’s service begins.

Inputs we collect

• Target assets (primary URLs, admin paths, subdomains)
• Environment (prod/stage), data handling expectations, out-of-bounds actions
• User roles and auth details (SSO/OIDC/SAML, MFA steps, password policy)
• API docs (Swagger/OpenAPI/Postman) if relevant to the web app
• Third-party integrations (e.g., Auth0, Stripe, Firebase, analytics)
• Change context (major release, new features, previous issues)

Together we choose the testing approach:

• Black-box (we test like an outsider, with minimal knowledge),
• Grey-box (we have user accounts and some documentation), or
• White-box (we have detailed documentation and, optionally, code or architecture diagrams).

We also define guardrails: when to test (to avoid peak usage), what not to touch (for example, destructive actions in production), and who to notify if something unusual is detected. Here, we also discuss safety controls (rate-limit tuning, WAF rules, test windows, alert routing).

The outcome is a short Rules of Engagement document: what’s in scope, who the contacts are, which accounts we’ll use, and how success will be measured.

Artifacts

• Rules of Engagement (RoE): time windows, constraints, stop-conditions
• Access plan: accounts per role, MFA procedure, allowlist/VPN details
• Scope map: in/out of scope, priority paths, API inventory (if applicable)

‍

Phase 2: Reconnaissance & Automated Discovery

In this phase we map the attack surface so later testing is focused and efficient. We combine authenticated and unauthenticated crawling with targeted fingerprinting to understand what exists, how it’s exposed, and where risk is likely to concentrate. Think of this as drawing the blueprint before stress-testing the structure.

What we do

• Crawling & enumeration: Discover pages, forms, parameters, and SPA routes in both anonymous and logged-in states.
• Fingerprinting: Identify frameworks, server software, CDNs, CMS plugins, third-party scripts, and build artifacts (e.g., sourcemaps) to understand likely weaknesses.
• Automated checks: Run tuned scanners for missing headers, weak TLS, known CVEs in front-end libraries, exposed directories, default endpoints, and misconfigurations.
• Workflow mapping: Manually trace critical paths (registration, login, payment, profile, admin actions) to prioritize later manual testing.
• API touchpoints: Note where the web app calls internal/external APIs; if API docs were provided, align discovered endpoints to the spec.

Signals we look for

• Hidden or unlinked paths (e.g., /admin, /backup, staging subdomains)
• Materials useful to attackers (stack traces, verbose errors, exposed sourcemaps, S3 links)
• Dependency/version clues (JS bundles, headers) that imply patching or config work
• Inputs that accept complex data (file uploads, rich text, JSON bodies) and warrant deeper testing

Safety controls
We respect any rate-limit, WAF, or schedule constraints defined in the RoE. If automated activity triggers alerts, we throttle or coordinate exceptions with your team.

Artifacts

• Surface Map: inventories of routes, parameters, roles/states tested, and discovered API calls
• Preliminary Findings List: candidates for validation (not yet confirmed vulns)
• Priority Workflow Notes: the flows we will probe most deeply in Phase 3

‍

Phase 3: Validation & Exploitation

Here we turn candidates into confirmed findings. Automated tools intentionally over-report; we manually verify each item, measure real-world impact, and, where safe, demonstrate how weaknesses can be chained. The aim is to remove noise and show exactly what an attacker could achieve.

Process pipeline

• Triage & de-duplication: Consolidate overlapping scanner alerts; discard false positives.
• Controlled proof: Reproduce issues with targeted payloads and instrumented requests; capture before/after evidence.
• Contextualization: Assess exploitability by role/tenant, data sensitivity, and blast radius; escalate only within RoE.

Areas we probe (examples)

• AuthN/AuthZ: Login bypass, weak flows, RBAC/ABAC gaps, IDOR, cross-tenant data access, privilege escalation.
• Session management: Token entropy and transport, fixation/rotation, logout behavior, cookie flags (Secure/HttpOnly/SameSite), JWT alg/kid misuse.
• Data protection & crypto: Mixed content, weak cipher suites, secret/key handling, insufficient encryption for sensitive fields.
• Input handling & injection: SQLi (error/boolean/time), XSS (reflected/stored/DOM), command/OS injection, template injection, path traversal, SSRF.
• File & content handling: Type/size validation bypass, polyglot files, media processing edge cases, storage path traversal.
• Web platform controls: CORS misconfig, CSP bypass, clickjacking, CSRF, cache poisoning, request smuggling (where applicable).
• Business logic: Step-skips, replay, pricing/quantity manipulation, quota abuse, order-of-operations flaws, race conditions.

Safety controls
High-impact techniques (e.g., time-based payloads, deserialization probes) are pre-approved and rate-limited per RoE. Destructive actions are out-of-bounds unless explicitly authorized.

Artifacts

• Verified Findings: each with reproduction steps, requests/responses, and screenshots/logs
• Exploit Chains (if present): how seemingly minor issues combine into meaningful impact
• Impact Notes: affected roles/tenants/data and recommended containment until fix

‍

Phase 4: Analysis & Reporting

We convert technical results into decision-quality guidance. The report explains what each issue is, where it occurs, why it matters to your organization, and how to fix it—the parts your engineers, leaders, and auditors respectively need.

What we analyze and document

• Root cause: design flaw, missing control, insecure default, or patch gap
• Affected components: URLs, parameters, roles/tenants, API endpoints
• Exploitability & impact: likelihood, attacker effort, and business exposure
• Prioritization: severity via OWASP/CVSS, adjusted by context (public vs internal, data class, compensating controls)
• Remediation: concrete code/config changes, dependency targets, and monitoring rules to prevent regression

Report structure

• Executive Summary: scope, goals, highest-risk items, and recommended next steps
• Methodology: what we tested, how, and any limitations (for auditability)
• Findings Catalogue: prioritized issues with evidence, severity, and remediation
• Appendices: raw request/response samples, wordlists, test accounts used, tooling notes
• Compliance Mapping (optional): OWASP Top 10/ASVS and SOC 2/ISO/NIST linkages

Artifacts

• Penetration Test Report (PDF): audit-ready, with executive and technical sections
• Prioritized Fix List: a one-page “do these first” view for engineering leads
• Issue Register (CSV/JSON, optional): importable for Jira/Boards with IDs, owners, SLAs

‍

Phase 5: Remediation & Retesting

Finding issues is only valuable if they’re resolved and verified. We remain engaged as your engineers implement fixes, then re-run the original proofs to confirm risk is actually reduced.

Remediation support

• Clarify reproduction steps; review proposed code/config patches
• Recommend secure defaults (headers, CSP, cookie policy), dependency versions, and CI guardrails (SAST/DAST baselines, secret scanning)

Retest workflow (included, unlimited)

• Request: you flag items as fixed and provide relevant diffs or configs
• Verify: we replay PoCs under the same auth/tenant context; extend checks to adjacent paths to catch regressions
• Record: update each item to Remediated, Partially Remediated, or Still Present, with fresh evidence

Evidence & attestation

• Retest outcomes are appended to the report for audit trails and customer assurance
• Optional Attestation Letter confirms scope, dates, and remediation status without exposing technical detail

Artifacts

• Retest Addenda: dated verification steps and outcomes per item
• Attestation (optional): concise external-facing confirmation of testing and fix verification

‍

What We Need to Start (Checklist)

• Targets: URLs/domains; admin paths; subdomains in scope
• Accounts: one test user per role (MFA steps documented)
• Access: allowlist/VPN details; any headers/tokens required
• Constraints: blackout windows; actions to avoid; rate-limit/WAF tuning
• Docs (optional): architecture notes; API specs (Swagger/Postman); role matrix
• POC: primary contact and escalation path

‍

FAQs

Will production be affected?
We default to safe, read-oriented techniques and coordinate any high-impact actions. RoE defines stop-conditions and escalation.

Do you test third-party services?
We assess your configuration and integration (tokens, callbacks, claims, scopes). Vendor platform internals are out of scope unless explicitly authorized.

How do you decide severity?
CVSS + OWASP risk, adjusted for exploitability, exposure, and business impact. We document assumptions and affected components.

What’s included post-report?
Remediation Q&A, unlimited retesting, and (optionally) an attestation letter.

‍

Learn More