TA AzeezCode

Penetration testing

A methodology built around evidence, authorisation and remediation

Testing begins only after scope and permission are agreed. The objective is not simply to identify vulnerabilities, but to understand root cause, explain impact, support remediation and verify the fix.

  1. 01

    Scope confirmation

    Written authorisation, in-scope hosts and applications, testing window, rules of engagement, emergency contacts and data-handling agreement before a single request is sent.

  2. 02

    Reconnaissance

    Passive information gathering, technology fingerprinting and documentation review, staying strictly inside the agreed scope.

  3. 03

    Attack-surface mapping

    Enumerating routes, parameters, roles, file handlers, integrations and background jobs to build a testable inventory.

  4. 04

    Authentication testing

    Credential handling, brute-force resistance, session issuance, fixation, logout, password reset and multi-factor flows.

  5. 05

    Authorisation testing

    Horizontal and vertical access control, IDOR, forced browsing and server-side enforcement of every client-side restriction.

  6. 06

    Input validation testing

    Injection classes, XSS contexts, SSRF, XXE, deserialisation and file-upload handling with safe, non-destructive payloads.

  7. 07

    Business-logic testing

    Workflow sequencing, price and quantity manipulation, race conditions, and abuse of legitimate features.

  8. 08

    Evidence collection

    Minimal reproducible requests, sanitised screenshots, timestamps and affected endpoints. No customer data is retained.

  9. 09

    Risk assessment

    CVSS v3.1 base scoring adjusted for real business context, so remediation is prioritised by impact rather than tool severity.

  10. 10

    Remediation guidance

    Concrete code-level fixes written for the team's stack, with secure patterns and references, not generic advice.

  11. 11

    Retesting

    Verifying each fix, checking for regressions and confirming the root cause was addressed rather than the symptom.

  12. 12

    Final reporting

    Executive summary, technical findings, evidence, risk ratings, remediation status and a prioritised roadmap.

Reporting

What a security deliverable should communicate

A useful report should help both technical and non-technical stakeholders understand what was found, why it matters and what needs to happen next.

Report structure

  • Executive summary for non-technical stakeholders
  • Scope, authorisation and testing context
  • Finding title and affected functionality
  • Security impact and business relevance
  • Sanitised reproduction steps and evidence
  • Root-cause explanation where identifiable
  • Practical remediation guidance for the application stack
  • Retest results and closure status
  • Prioritised next actions where multiple findings exist

Sanitised sample finding 

Finding ID:   WEB-001
Title:        Missing server-side authorisation on invoice access
Severity:     High
Affected:     GET /invoices/{id}
Status:       Remediated and retested

Summary:      An authenticated user could modify the invoice
              identifier and attempt to access another customer's
              resource because ownership was not enforced in the
              server-side lookup.

Evidence:     Sanitised request showing identifier substitution
              between two authorised test accounts.

Root cause:   Invoice lookup used the resource identifier without
              also scoping the query to the authenticated customer.

Remediation:  Enforce ownership server-side by retrieving the
              invoice using both invoice ID and authenticated
              customer ID.

Retest:       Customer A can access Customer A's invoice.
              Customer A receives 404 when requesting Customer B's
              invoice. No cross-account data is returned.

Rules of engagement

Testing is performed only with written authorisation or inside environments specifically designed for security training. I avoid destructive payloads, denial-of-service activity and unnecessary access to data that is not required to demonstrate the security issue.

Evidence is sanitised before publication, and confidential client information, credentials, private endpoints and sensitive implementation details are not disclosed.