Grade My Investments Technology Observatory
GMI · TECHNOLOGY OBSERVATORY // ALL SYSTEMS NOMINAL
ENGINEERED BY LEOPARD DATA

Ethical Hacking Testing

With Grade My Investments now live in production, we are conducting an active ethical hacking program to verify the security of the platform end-to-end. This page documents the vulnerability classes we are probing for, the methodology we use, and how we leveraged Claude Code (Anthropic's coding agent) to perform a complete source code security review and remediate every OWASP finding before going live.

ETHICAL HACKING METHODOLOGY
rendering diagram…
flowchart TB
    subgraph P1[Pillar 1 - Static Review]
        CC[Claude Code<br/>Whole-repo scan]
        OT[OWASP Top 10<br/>10 focused passes]
        FD[37 Findings<br/>Documented]
        REM[All Remediated<br/>before launch]
        CC --> OT --> FD --> REM
    end
    subgraph P2[Pillar 2 - Active Probing]
        IDOR[IDOR Testing<br/>Cross-account access]
        SQLi[SQL Injection<br/>Payloads vs MySQL]
        XSS[XSS - CSRF<br/>Priv Escalation]
        MISC[Misconfig - SSRF<br/>Path Traversal]
        IDOR --> SQLi --> XSS --> MISC
    end
    subgraph P3[Pillar 3 - Monitoring]
        AI[App Insights<br/>Runtime anomalies]
        AM[Azure Monitor<br/>Alerts]
        AUDIT[Audit Logs<br/>403 - Auth events]
        AI --> AM --> AUDIT
    end
    P1 --> P2
    P2 --> P3
    classDef app fill:#1f2630,stroke:#C0894E,color:#F3EFE8;
    classDef svc fill:#241c14,stroke:#E2B583,color:#F3EFE8;
    classDef data fill:#22201a,stroke:#C0894E,color:#EBD3AE;
    classDef ext fill:#1b1f27,stroke:#5A616B,color:#C4C0B8;
    classDef sec fill:#1d2733,stroke:#5cc8e0,color:#eafaff;
    class CC,OT sec
    class FD,REM app
    class IDOR,SQLi,XSS,MISC svc
    class AI,AM,AUDIT data
Three-pillar process: static review, active probing, and continuous monitoring.

Program Overview

Ethical hacking — also called authorized penetration testing — is the practice of deliberately attacking your own production system, with full authorization, in order to find vulnerabilities before a real attacker does. Every test is performed by the Grade My Investments team against Grade My Investments’ own infrastructure, against accounts the team owns, and under controlled conditions that will not affect real customer data.

The program has three pillars:

  • Static analysis with Claude Code — complete source code review of every project in the solution against the OWASP Top 10.
  • Active probing — live testing of the production endpoints, the Blazor web apps, and the MAUI mobile app for the vulnerability classes listed below.
  • Continuous monitoring — Application Insights, Azure Monitor alerts, and audit logs to detect anomalous behavior.

Vulnerability Classes We Test For

Our test plan covers the full OWASP Top 10 (2021) plus several adjacent vulnerability classes that commonly affect modern SaaS platforms. Each item below lists the attack technique we exercise and the Grade My Investments component we exercise it against.

Critical
Insecure Direct Object References (IDOR)

OWASP A01 — Broken Access Control

We test every API endpoint that accepts an accountId, reportId, fileId, folderId, or similar entity identifier by logging in as Account A and attempting to read, modify, or delete resources belonging to Account B. Endpoints must return HTTP 403 Forbidden on cross-account access.

Critical
SQL Injection

OWASP A03 — Injection

We probe every input that ultimately reaches the MySQL database — symbol lookups, filter strings, report parameters, search boxes — with payloads such as '; DROP TABLE Accounts;--, ' OR 1=1--, time-based blind payloads, and union-based extraction strings. Entity Framework Core parameterization and parameterized stored procedures must reject every payload.

Critical
Cross-Site Scripting (XSS)

OWASP A03 — Injection

We submit reflected, stored, and DOM-based XSS payloads (e.g. <script>alert(1)</script>, <img src=x onerror=alert(1)>, event-handler payloads) into every free-text field in the Client Web, Admin Web, and MAUI mobile apps. Blazor’s automatic output encoding plus our CSP headers must prevent execution.

High
Cross-Site Request Forgery (CSRF)

OWASP A01 — Broken Access Control

We craft external HTML pages that auto-submit state-changing requests (POST/PUT/DELETE) against the Grade My Investments API while a victim browser holds an active session. Bearer-token authentication on every request means cookie-replay forgery should fail outright.

High
Broken Authentication & Session Hijacking

OWASP A07 — Identification and Authentication Failures

We test token replay, expired-token reuse, token theft from localStorage (we deliberately do not use it), session fixation, and idle-timeout enforcement. We also verify that OAuth flows use PKCE on mobile and that no client secret is shipped in the MAUI binary.

High
Privilege Escalation & Broken Role Enforcement

OWASP A01 — Broken Access Control

Acting as a standard user, we attempt to call admin-only endpoints (GetSystemDashboard, GetSystemStats, account management endpoints, system jobs). All admin endpoints must enforce the Support or higher role from the Admin Web Azure AD identity.

High
Mass Assignment / Over-Posting

OWASP A04 — Insecure Design

We POST JSON with extra fields the user should not be able to set — Enabled, EmailValidated, AccountValidated, StripeCustomerId, ExternalKey, Created — and verify the server ignores them. Endpoints deserialize into request DTOs, not domain entities.

Critical
Hardcoded Secrets & Credential Exposure

OWASP A02 — Cryptographic Failures

We inspect every shipped artifact — the Blazor WASM bundle, the MAUI binaries, public source, and any deployment artifact — for leaked Stripe keys, SendGrid keys, Twilio credentials, database passwords, JWT secrets, or function keys. All real secrets must live only in Azure Key Vault.

Medium
Server-Side Request Forgery (SSRF)

OWASP A10 — Server-Side Request Forgery

We test any field that might be interpreted as a URL by the server. Grade My Investments does not accept user-supplied URLs for server-side fetching — outbound calls are restricted to Financial Modeling Prep and Stripe via an allowlist — but we verify that constraint holds.

High
Path Traversal & Arbitrary File Access

OWASP A01 — Broken Access Control

We submit payloads like ../../etc/passwd and Azure-blob-relative paths to any endpoint that resolves a file name or folder name. Blob access must be account-scoped through signed access paths, not raw file system paths.

Medium
Open Redirect

OWASP A01 — Broken Access Control

We test all OAuth callback and post-login redirect parameters with external URLs to verify the app only redirects to allowlisted Grade My Investments hosts — protecting users from credential phishing through redirect abuse.

Medium
Insecure Deserialization & XXE

OWASP A08 — Software and Data Integrity Failures

We exercise every endpoint that accepts JSON or file uploads with malformed payloads, polyglots, and (where XML is parsed) external entity references. JSON deserialization uses System.Text.Json with constrained DTO contracts; no BinaryFormatter is used.

High
Vulnerable & Outdated Components

OWASP A06 — Vulnerable and Outdated Components

We continuously audit NuGet dependencies, Bootstrap, Syncfusion, and any client-side library against known-CVE databases. Dependabot watches the repo; the CI build runs dotnet list package --vulnerable.

Medium
Security Logging & Monitoring Gaps

OWASP A09 — Security Logging and Monitoring Failures

We confirm that authentication failures, authorization rejections (HTTP 403), and payment events are logged with sufficient context (user, timestamp, request ID) to support post-incident forensics.

Medium
Rate-Limit Bypass & Resource Abuse

Adjacent — Business Logic / DoS

We measure how the API behaves under bursts of authenticated and unauthenticated requests, and verify that report generation, blob downloads, and Claude AI calls are throttled per account so a single account cannot exhaust shared resources.

High
Security Misconfiguration

OWASP A05 — Security Misconfiguration

We scan for missing security headers (HSTS, X-Frame-Options, X-Content-Type-Options, CSP), permissive CORS, verbose error pages, exposed Swagger or diagnostic endpoints, and unrestricted Azure storage containers.

How We Used Claude Code for Source Code Review

Before going to production, we used Claude Code — Anthropic’s agentic coding tool running Claude Opus — to perform a complete, project-wide security review of every line of source code in the Grade My Investments solution. Claude Code is uniquely well-suited to this task because it can read the entire repository (every C# file, every Razor page, every Bicep template, every Pulumi program, every console app, every test) and reason about cross-cutting concerns the way a senior security engineer would.

The Review Process
  1. Full-repo enumeration. We asked Claude Code to walk the entire solution and inventory every Azure Functions endpoint, every service method, every database query, every authentication path, every secret-handling site, and every external API call.
  2. OWASP Top 10 pass. Claude Code re-read the codebase ten times — once per OWASP category — looking specifically for the patterns that match each category. For example, the A01 pass searched for endpoints that accepted resource identifiers without ownership checks.
  3. Finding documentation. Each finding was written up with severity, OWASP category, exact file and line reference, attack scenario, and a recommended remediation. The full output lives in docs/gmi-owasp-security-scan.md in this repository.
  4. Remediation in code. Claude Code then drafted the actual code changes for each finding — the IDOR authentication middleware, the Bearer-token validator, the account ownership extension, the request-DTO refactor for mass assignment, the Key Vault migration for hardcoded secrets, and the security header configuration.
  5. Verification. A human engineer reviewed every change Claude Code proposed, integration tests were updated, and the full security scan was re-run to confirm each finding moved from Open to Remediated.
Why Claude Code Specifically
  • Whole-repo reasoning. Unlike line-level static analyzers, Claude Code understood the relationship between an endpoint, the service it called, the repository under that, and the database it ultimately hit — which is exactly the chain IDOR exploits attack.
  • Frame-aware analysis. Claude Code knew which checks Entity Framework Core already provides, which checks Blazor already provides, and where the gaps were — so it spent its time on real findings, not noise.
  • Remediation, not just detection. Most scanners produce a report. Claude Code produced both the report and the matching pull-request-quality code changes.
  • Repeatability. The same agent will be re-run after major changes to keep the scan current.

Outcome — Every OWASP Finding Remediated

The Claude Code review produced 37 findings across the OWASP Top 10 in the pre-production codebase. As of production launch, every one of them has been remediated or confirmed as a non-issue.

Severity Findings Remediated Open
Critical 11 11 0
High 12 12 0
Medium 11 11 0
Low 3 3 0
Total 37 37 0

Headline remediations included a three-layer IDOR defense (authentication middleware + Google token validator + per-endpoint ownership check across 42 endpoints), a Key Vault migration for every hardcoded Stripe, SendGrid, Twilio, and database secret, a request-DTO refactor on every domain-entity endpoint to kill mass assignment, and role-based authorization enforcement on every admin endpoint.

Ethical Testing Ground Rules

  • Authorization. All testing is performed by the platform owner against the platform owner’s own infrastructure.
  • Test accounts only. All exploit attempts are run against accounts the team controls. No real customer account is ever the target.
  • Production-safe payloads. No destructive payloads — we test that DROP TABLE is rejected, we do not actually drop tables.
  • No DoS. Rate-limit testing is conducted at controlled volumes, not flood-level. We measure throttling thresholds, we do not try to take the platform down.
  • Findings are logged, then fixed. Anything discovered during live probing flows through the same scan-doc + remediation pipeline used pre-launch.
Vulnerability Classes Tested
  • IDOR
  • SQL Injection
  • Cross-Site Scripting (XSS)
  • CSRF
  • Broken Authentication
  • Privilege Escalation
  • Mass Assignment
  • Hardcoded Secrets
  • SSRF
  • Path Traversal
  • Open Redirect
  • Insecure Deserialization / XXE
  • Outdated Components
  • Logging Gaps
  • Rate-Limit Bypass
  • Security Misconfiguration
Claude Code Coverage

Every project in the solution was reviewed:

  • Azure Functions API
  • Services layer
  • Data Access layer
  • Client Web (Blazor WASM)
  • Admin Web (Blazor WASM)
  • MAUI Mobile app
  • REST client libraries
  • All background console apps
  • Pulumi infrastructure code
  • CI/CD pipelines
Testing Tooling
  • Claude Code — Source code security review & remediation
  • OWASP ZAP — Automated dynamic scanning
  • curl / Postman — Manual endpoint probing
  • Browser DevTools — XSS / token inspection
  • Dependabot — Dependency CVE alerts
  • Application Insights — Runtime anomaly detection
Current Status

37 / 37 OWASP findings remediated before production launch.

Active ethical hacking program running against production to verify defenses hold in the live environment.

Related Pages