Engagement overview
The client operates a multi-tenant software platform through which an agency builds, manages, and publishes websites for its customers.
A central application handles authentication, project membership, content, media, publishing workflows, and internal planning data. A separate rendering service serves each published website under its own domain.
The platform was approaching the point where it would begin hosting real client data. The owner commissioned an independent assessment to answer one practical question:
What must be true before this platform can responsibly host customer data?
Answering that question required more than a conventional vulnerability scan or a narrow web application penetration test.
The engagement progressed through three completed phases. External reconnaissance established what an unauthenticated attacker could discover and reach. Live penetration testing then examined authentication, authorization, tenant isolation, upload handling, business logic, and infrastructure exposure. Finally, a source-informed threat model evaluated the architecture behind the observed behaviour: credentials, trust boundaries, deployment provenance, destructive attack paths, backup and recovery, monitoring, and incident readiness.
Evidence strength was kept separate from severity.
Material claims were classified as:
- Verified from source or configuration
- Verified through live authorized testing
- Client-confirmed
- Inferred from available evidence
- Unknown and requiring additional evidence
Controls that could not be proven were not presented as facts. Hypotheses that did not survive testing were documented as ruled out rather than quietly omitted.
The result was not only a vulnerability assessment. It was a production-readiness decision supported by evidence, a target-state security architecture, and a prioritized engineering plan for changing that decision.
Phase timeline
External reconnaissance
CompleteMapped the observable attack surface across DNS, TLS, exposed services, application hosts, object storage, monitoring endpoints, and proxy-bypass paths. This phase established what an unauthenticated attacker could discover and reach before application credentials or source access were introduced.
The work covered:
- DNS and hostname discovery
- TLS posture
- Public and out-of-band services
- Reverse-proxy behaviour
- Direct-port exposure
- Storage endpoints
- Monitoring and infrastructure services
- Initial attack-path hypotheses
The resulting attack-surface map shaped the authenticated and source-informed phases that followed.
Authorized penetration testing
CompletePerformed live, authorized, non-destructive testing of the deployed platform.
Coverage included:
- Authentication
- Session handling
- Horizontal and vertical authorization
- Cross-tenant access
- IDOR
- Privilege escalation
- Mass assignment
- CSRF
- Rate limiting
- File upload
- Input injection
- Renderer behaviour
- Business logic
- Infrastructure exposure
The testing also verified remediation of earlier critical findings and confirmed which application-layer controls remained effective under adversarial use rather than source inspection alone.
Test data was restricted to isolated tester-owned projects. No pre-existing tenant data was modified or deleted.
Threat modelling and security architecture
CompletePerformed an evidence-disciplined static assessment against a pinned source revision and the available infrastructure configuration.
The work covered:
- Architecture reconstruction
- Asset identification
- Security invariants
- Trust boundaries
- Data-flow modelling
- STRIDE analysis
- Attack trees
- Authentication and session design
- Tenant-isolation architecture
- Credential blast radius
- Object-storage and database privileges
- Renderer and browser attack paths
- Deployment provenance
- Supply-chain risk
- Backup and ransomware exposure
- Failure modes
- Detection and incident readiness
- Assume-breach scenarios
The assessment concluded with:
- A target-state security architecture
- Ten proposed architecture decisions
- Implementation-ready remediation specifications
- Migration and rollback considerations
- Security regression-test requirements
- Detection and incident-response specifications
- Objective closure criteria for each material finding
Incident-response and recovery validation
PlannedOnce the backup and recovery architecture has been implemented, conduct a controlled exercise covering:
- Clean-environment restoration
- Destructive data-loss scenarios
- Credential rotation
- Compromised-host response
- Evidence preservation
- Incident ownership and escalation
- Recovery sequencing
- Measured RPO and RTO
- Post-exercise remediation
The objective is to verify that the new controls function under realistic failure conditions rather than existing only as documentation.
Methodology
The engagement combined black-box, authenticated, white-box, and architectural analysis. Each method answered a different question.
What can an unauthenticated attacker discover and reach?
Which reachable paths can be exploited in the deployed application?
How are identities established, maintained, revoked, and protected?
Can a user cross project, tenant, role, or object boundaries?
What security behaviour is implemented in the reviewed revision?
How can individual weaknesses combine across trust boundaries?
What authority does an attacker inherit after compromising an application process, service account, or operator identity?
Can the platform detect, contain, and recover from a destructive event?
This combined approach prevented source-level assumptions from being confused with production facts and prevented live testing from being treated as complete coverage of architectural and operational risk.
Selected findings
anonymized · exploit details withheld · click to expand
The selected findings below demonstrate the range of the assessment. They are not the complete risk register.
BACKUP-001 High 15 No production backup or disaster-recovery capability
No independent off-box backup existed for the primary database or object storage at the time of assessment.
The application’s internal "backup" feature consisted of page-version snapshots stored inside the same database. Those snapshots could help recover individual content changes, but they provided no protection against database loss, storage loss, ransomware, destructive compromise, or host failure.
The risk was amplified by:
- Hard-delete code paths
- Fully privileged database credentials
- Root-level object-storage credentials
- No independent recovery account
- No tested restore procedure
A single ransomware event, destructive intrusion, infrastructure failure, or operator error could result in permanent and unrecoverable loss of all tenant data.
No control with disaster-recovery value existed at the time of assessment.
- Off-box database backups
- Independent object-storage replication
- Separate backup credentials
- Immutable or versioned storage
- Encryption
- Defined retention
- Backup-failure alerting
- Scheduled clean-environment restore drills
The finding cannot be closed merely because backup files exist. Closure requires a successful restore into a clean environment, verification of platform functionality, and evidence that the documented recovery objective can be met.
DEPLOY-001 High 12 Running production build not attributable to a reviewed commit
The running production application could not be mapped to a specific reviewed source revision.
The deployment used manually built images and mutable references. The application health endpoint did not expose build identity, and the live environment demonstrated behaviour that differed from the reviewed source in both directions.
The client could not prove:
- Which code was running
- Whether a source-reviewed control existed in production
- Whether a deployed fix was included
- Which artifact was known-good
- Which version should be used during rollback
- Whether a registry or build compromise had changed the runtime
- Build from a clean and approved commit
- Record the full commit SHA
- Generate an immutable image digest
- Sign and verify the digest
- Deploy by digest rather than mutable tag
- Expose build metadata through an operational endpoint
- Record the deployment operator and timestamp
- Retain the previous known-good digest
Every running production artifact must map to an approved repository commit, a recorded build, an immutable registry digest, and a named deployment event.
EDGE-001 High 12 Conditional Production served an internal self-signed TLS certificate
The deployed platform used an internally issued certificate rather than a publicly trusted production certificate.
The rating depends on the intended operating model.
If the service is deliberately private and every managed client securely trusts the organizational CA, the condition may be acceptable. If the platform is intended to serve public client websites, it is a release-blocking control failure.
Users cannot establish a normally trusted browser connection. Certificate warnings train users to bypass trust failures, and security controls such as HSTS cannot be safely relied upon until the certificate path is correct.
- Replace the internal certificate with a valid production certificate
- Confirm normal browser and system trust
- Verify renewal
- Enable HSTS only after trusted HTTPS is stable
- Prevent direct application ports from bypassing the edge
CRED-001 / CRED-002 Medium 10 each Application used administrative database and object-storage identities
The application authenticated to object storage using a root-level credential and to PostgreSQL using a database-owner identity.
An application compromise would therefore inherit infrastructure-administration privileges rather than only the data operations required for normal runtime behaviour.
A compromised application process could potentially:
- Read or modify data across all tenants
- Delete production content
- Change storage policy
- Create additional service credentials
- Alter or destroy database objects
- Expand persistence
- Amplify the consequences of the missing backup system
Introduce separate identities for:
- Database ownership
- Database migration
- Application runtime
- Background workers
- Logical backup
- Object-storage runtime
- Object-storage administration
- Backup replication
- Restore operations
TENANT-001 Medium 8 Cross-tenant write path in the shared preset library
An authenticated user could supply an arbitrary project identifier when creating a reusable block preset.
Reads remained scoped, and the issue did not provide direct access to another tenant’s content. However, it permitted unauthorized writes into another project’s preset library or the global shared library.
The issue created a cross-tenant integrity violation:
- Unauthorized content pollution
- Shared-library manipulation
- Potential workflow disruption
- Loss of confidence in tenant boundaries
The wider authorization architecture remained materially sound. The issue was isolated to one write path that performed authentication without enforcing project-scoped authorization before persistence.
- Require an explicit project capability on the exact target project
- Allow global preset creation only for platform administrators
- Complete authorization before any database insert
- Return a deterministic denial
- Add negative tests proving that unauthorized requests create no record
Controls independently validated
A balanced assessment should identify effective controls as clearly as weaknesses. The following application-layer controls were verified through source review and, where applicable, challenged through live authorized testing.
Project authorization was derived server-side from database-backed membership rather than from client-supplied user, tenant, or role values.
Cross-tenant object access, privilege escalation, and mass-assignment attempts failed during live testing.
No general tenant-isolation collapse was identified.
Application queries were constructed through parameterized ORM operations rather than attacker-controlled SQL concatenation.
Source tracing found no exploitable raw-query path, and live injection probes did not produce database-level execution.
The upload pipeline used:
- File-type allowlisting
- Magic-byte signature verification
- Size validation
- Type revalidation
- Object metadata checks
Verified controls included:
- Secure cookies
- HttpOnly cookies
- SameSite protection
- Limited session lifetime
- Session revocation after password reset
- Stronger password requirements
- Rate limiting
- Modern password hashing
Several malformed or unauthorized requests returned imperfect error responses, including internal server errors where a cleaner denial would have been preferable.
However, the tested routes failed closed and did not return unauthorized tenant data.
This distinction was recorded: poor error handling was reported separately from an authorization bypass.
Architecture and trust boundaries
Public application traffic should enter through the edge proxy. Live testing identified deployment drift and out-of-band services that bypassed this intended boundary. Those exceptions were recorded separately as infrastructure and deployment findings.
The platform’s primary operational weakness was recoverability: production data in the database and object storage had no independent off-box recovery copy (BACKUP-001).
The complete assessment included:
- Full data-flow diagrams
- Trust-boundary analysis
- Attack trees
- Credential-flow modelling
- Assume-breach paths
- Target-state architecture
- Migration requirements
Deliverables and outcome
- External reconnaissance and security-audit report
- Follow-up verification and penetration-test report
- 135-page threat model and attack-surface assessment
- Risk register with scored and evidence-classified findings
- Data-flow diagrams and attack trees
- Target-state security architecture
- Ten proposed architecture decisions
- Implementation-ready remediation specifications
- Security regression-test requirements
- Acceptance criteria and closure procedures
- Phased remediation roadmap
The engagement produced a connected set of deliverables rather than three isolated reports.
- The reconnaissance report documented the externally observable attack surface.
- The penetration-test report verified exploitable behaviour, retested earlier findings, and recorded controls that resisted active testing.
- The threat model connected those observations to source code, trust boundaries, credentials, deployment, recovery, and operational failure modes.
- The target-state architecture and implementation specifications translated the resulting risks into engineering work with objective acceptance and closure criteria.
The platform was not yet ready to host real client data, but the primary reason was not a collapse of its application security model.
Authentication and tenant isolation were materially sound.
The release-blocking risk was recoverability, amplified by privileged infrastructure credentials, destructive data paths, uncertain deployment provenance, and limited incident readiness.
This distinction mattered. Instead of recommending a broad rewrite of a functioning application layer, the engagement identified the smaller set of architectural and operational controls that would materially change the platform’s risk posture.
The client received:
- Immediate actions for the first seven days
- A 30-day hardening programme
- Longer-term architectural improvements
- Defined implementation owners
- Acceptance and negative-test requirements
- Migration and rollback considerations
- Concrete evidence required to close each finding
The result was a defensible production decision and an engineering path for changing that decision.
The planned incident-response and recovery exercise will complete the lifecycle by testing whether the implemented backup, containment, and restoration controls work under realistic destructive conditions.
Client perspective
“We did not receive a scanner dump or a generic list of findings. Haroun reconstructed the system, tested the controls that mattered, and separated confirmed weaknesses from assumptions. The final deliverable gave us a prioritized remediation plan, a target security architecture, and acceptance criteria precise enough for our engineers to implement and independently verify.”
Confidential European Software Company Pending client approval
“Haroun did far more than give us a list of vulnerabilities. He reconstructed the platform end to end - from the externally reachable attack surface and live application behaviour through to the source code, trust boundaries, credentials, deployment process, and recovery model.
His work gave us a technically defensible view of where the platform actually stood. He confirmed which controls held up under adversarial testing, separated verified findings from assumptions and unknowns, and identified the operational risks that genuinely needed to block us from hosting client data.
What made the engagement especially valuable was the level of engineering detail behind the recommendations. Every material issue was connected to its technical cause, business impact, remediation priority, acceptance criteria, and a concrete method for verifying closure. We did not just receive a security report - we received a target architecture and an actionable plan our engineers could execute against.
The assessment changed the conversation from "do we think the platform is secure?" to "what exactly must be true before we can responsibly put it into production?"”
Confidential European Software Company Pending client approval
Sample material
The complete reports contain client-confidential architecture, infrastructure, source references, and exploit details and are therefore not published.
The samples below are anonymized and abridged. Client names, product names, domains, addresses, credentials, repository identifiers, source paths, and selected attack steps have been removed or generalized while preserving the assessment methodology, reasoning structure, and deliverable quality.