Authentication and sessions
Login, account recovery, multi-factor flows, session lifecycle and controls that protect authenticated access.
Singapore / Application security
Web application & API penetration testing.
Test the controls that protect user accounts, sensitive actions and connected systems—not only the issues a scanner can list.
Discuss your scope01 / Service fit
Test the application as a system.
A web application assessment should reflect how the application is actually used: its user roles, sensitive workflows, APIs, data flows and dependencies. The agreed scope can cover a public-facing application, an authenticated portal, supporting APIs or a defined combination of these components.
This service is suited to teams preparing for release, making a material change, responding to a customer or procurement requirement, or seeking independent assurance of an existing application.
RedHive conducts penetration testing for A*STAR’s Open Access Repository as part of an ongoing multi-year engagement. No findings, architecture or sensitive engagement details are disclosed.
02 / Scope
What we assess.
The final test scope is agreed before work begins. Coverage is selected around the application’s actual attack surface and the risks the engagement needs to address.
Access control
Role and object-level authorisation across users, administrative functions, records and API operations.
Business logic
Workflow sequencing, state changes, limits and assumptions that may be abused without relying on a conventional payload.
Input and data handling
Server-side processing, file handling, output encoding, sensitive data exposure and relevant injection paths.
API behaviour
Endpoint authentication, authorisation, data exposure, parameter handling and abuse of supported operations.
Integration boundaries
Agreed trust boundaries between the application and identity, payment, storage or other connected services.
03 / Method
How the engagement runs.
A defined process keeps testing safe, findings reproducible and remediation discussions useful to the delivery team.
- 01
Define the system
Agree target hosts and APIs, environments, user roles, accounts, dependencies, restrictions, exclusions and escalation contacts.
- 02
Map the attack surface
Understand reachable functions, trust boundaries, sensitive actions and data flows before deeper testing.
- 03
Test and validate
Combine appropriate automated checks with manual testing of access control, business logic and plausible attack paths.
- 04
Report and explain
Document reproducible evidence, realistic impact, severity rationale and practical recommendations; discuss findings with relevant stakeholders.
- 05
Retest agreed fixes
Verify remediated findings within the agreed retest scope and record whether the original exposure has been addressed.
04 / Deliverables
Outputs teams can act on.
Reporting separates decision-level priorities from the detail engineers need to reproduce and address each finding.
Management view
Scope, assessment context, overall exposure and prioritised remediation themes.
Technical findings
Reproduction steps, supporting evidence, affected components, impact and severity rationale.
Remediation guidance
Practical recommendations, clarification with the delivery team and retest status for agreed fixes.
05 / Boundaries
Assumptions and exclusions.
These points are confirmed for each engagement rather than assumed after testing starts.
Written authorisation
Only approved assets, environments and test activities are in scope. Ownership and third-party permissions must be clear.
Safe test conditions
Production constraints, test accounts, data handling, rate limits, maintenance windows and stop conditions are agreed in advance.
Explicit exclusions
Denial-of-service, social engineering, unrelated third parties and destructive actions are excluded unless separately authorised and planned.
A penetration test provides evidence about the agreed scope and test period. It is not a guarantee that every weakness has been found, and it does not by itself certify regulatory compliance.
06 / Related services
Adjacent coverage.
Start a conversation
Define the right test boundary.
Share the application, environments, user roles, key integrations and target timing. RedHive can then confirm what needs to be validated before a scope is agreed.