CaldorelAPPLICATION SECURITY
← Back to the assessment

Our methodology

Technical depth.
A clear, controlled process.

How we scope the assessment, investigate application risk, and turn findings into practical recommendations.

Explore what we test ↓View scope & pricing ↗

What we test

Look past the login.
Test what a user can really do.

Testing shaped around your application,
its users, and its agreed attack surface.

EXPLORE THE TESTING AREAS

From a security question
to a useful finding.

Choose an area to see what we examine and how findings are explained.

User
access
01 / Authentication

Who can sign in?

What we examine
We examine how the application verifies identity, including login and account-recovery flows within the agreed scope.
An illustrative question
Could a password-reset flow allow someone to take over another account?
What your team receives
If a weakness is identified, the report explains the affected flow, its potential impact, severity, and recommended remediation.

Illustrative questions, not findings from a client assessment. Applicable checks and reporting detail are agreed during scoping.

APPLICATION / ACCESS / DATA

Real workflows.
Meaningful security questions.

We map the agreed application, identify exposed entry points, and combine manual investigation with automated checks.

The areas below guide scoping. We agree the applicable checks, roles, and endpoints before testing.

See how testing runs ↓
01Authentication & account recovery

Can login or password-reset flows be bypassed or abused? We examine how the application verifies identity.

OWASP WSTG · Identity & authentication
02Permissions & data boundaries

Can one account reach another account’s records or use a higher-privilege function? We assess authorization across agreed roles.

OWASP WSTG · Authorization
03Sessions & sign-out

How are sessions established, maintained, and ended? We check session behavior and the protection of session identifiers.

OWASP WSTG · Session management
04Input handling & injection

Can unexpected input change application behavior? We investigate injection and client-side risks, including SQL injection and cross-site scripting where applicable.

OWASP WSTG · Input validation & client-side testing
05Business logic & sensitive actions

Can intended workflow rules be bypassed? We examine business logic in the application’s agreed sensitive operations.

OWASP WSTG · Business logic
06Exposed endpoints & configuration

What is exposed through agreed web routes, APIs, and deployment settings? We assess relevant entry points and information leakage.

OWASP WSTG · Information gathering & configuration

Your application sets the scope. Associated APIs are included only where listed. Source-code review, additional apps, and broader infrastructure require explicit agreement.

A controlled process

No guesswork about what happens next.

01 / PREPARE

Scope & authorize

We agree URLs, APIs, user roles, access, and the test window. Written authorization and rules of engagement set the boundaries.

02 / UNDERSTAND

Map the application

We identify the agreed endpoints, technologies, and entry points. This gives the assessment context before deeper testing begins.

03 / INVESTIGATE

Test & validate

Manual investigation and automated checks help us identify weaknesses and demonstrate their impact within the authorized scope. Critical findings are escalated during testing.

04 / EXPLAIN

Review & deliver

We write and peer-review the report, then walk through the findings and remediation priorities. Retesting follows the agreed statement of work.

METHODOLOGY

We use recognized guidance such as OWASP WSTG for relevant application checks and PTES for engagement structure, as appropriate to the scope. The agreed methodology describes what we assess and any limitations.

Explore the OWASP testing guide ↗
BEFORE KICKOFF

A clear start makes a better assessment.

We confirm the practical details with your technical contact before the test window.

  • Application URLs and agreed API documentation
  • Working test accounts for the agreed user roles
  • Access arrangements and a stable environment
  • Test window, exclusions, and escalation contacts

Useful beyond the assessment

A report for leadership.
Detail for engineering.

Understand the risk.
Decide what to fix next.

↗ILLUSTRATIVE STRUCTURE

WEB APPLICATION

Security
assessment.

01Executive summaryRisk & business impact
02Technical findingsSeverity, impact & remediation
03Assessment scopeCoverage & limitations

Illustrative layout, not a completed client assessment.

01 / CLARITY

See what matters.

An executive summary explains the assessment, the business impact of identified issues, and the priorities for decision-makers.

02 / ACTION

Give your team a next step.

Technical findings describe the affected areas, severity, potential impact, and remediation recommendations. We agree the reporting detail your team needs during scoping.

03 / CONTEXT

Talk through the results.

We peer-review the report before delivery. The walkthrough gives your team space to understand findings, discuss priorities, and ask questions.

Before you decide

Good questions.
Clear answers.

Have an unusual application or a specific deadline?
Start with a scope conversation.

How long does the assessment take?

Dates depend on the agreed scope, access readiness, and delivery availability. Testing and report dates are confirmed in the engagement documents before a slot is committed.

Does the test require source code?

The test approach and access are agreed during scoping. Authenticated testing uses agreed test accounts. Source-code review is a separate scope item unless explicitly included.

Will you implement the fixes?

Our report provides remediation recommendations. Implementing changes is the responsibility of your team unless separately agreed. We can discuss the findings during the walkthrough.

Is a retest included?

Only if it is included in your statement of work. Scope, request window, and scheduling are agreed explicitly.

Will this satisfy a customer or auditor?

The assessment provides findings and supporting security evidence. Tell us the recipient’s requirements during scoping. Audit acceptance, certification, and report-sharing requirements are not automatic.

How are sensitive findings handled?

We agree confidentiality, secure delivery, and data-handling requirements as part of the engagement. Access to sensitive findings is restricted to the people involved in the assessment.

Can you test more than a web application?

We offer broader testing capabilities, including mobile, cloud, and networks. These are separate engagements with their own scope and price.

What is needed before testing starts?

A signed scope, written owner/operator authorization, working access, and any required hosting-provider permissions. The test window and communication plan are agreed before kickoff.

Start with the right scope

What needs testing?
Let’s make it clear.

Tell us about your application, who needs the report,
and when you need it. We’ll work from there.

A scope conversation.
No testing without written authorization.