APPSEC
CZ SK EN
TESTING AND ANALYSIS / THE ATTACKER'S PERSPECTIVE

Testing and analysis

Find weaknesses before someone else exploits them. An authorised test replaces assumptions about security with verified facts and clear priorities.

FROM TESTING TO REMEDIATION

Verify the weakness. Show the impact. Guide the fix.

Application API Business data Test deliverable Verified path to data Evidence: access via API Impact: exposed data Fix: authorisation checks
  1. Assess the environment
  2. Demonstrate the impact
  3. Recommend remediation
Verified path → data impact → actionable recommendation.

In this example, an API authorisation flaw exposes data. Testing provides evidence and impact; code analysis helps identify the cause and a suitable fix. We agree on the methods and scope beforehand.

Objective
Verify real risks in applications, software and infrastructure.
Principle
Written authorisation, an agreed scope and safe Rules of Engagement.
Deliverables
Evidence, impact, priority and recommended remediation for every finding.
Services

Three services based on what you need to verify.

Blackhat test

An overall view of key technical and organisational weaknesses from an attacker's perspective.

Typical situationWe need the overall picture

Service details

Penetration testing

In-depth verification of what can be exploited in a specific application, API or infrastructure.

Typical situationWe have a specific target

Service details

Software security analysis

Architecture, source code, dependencies and application behaviour. Deliverables for developers.

Typical situationWe develop our own software

Service details
SAMPLE DELIVERABLE

A finding your team can act on

Each finding describes impact, evidence and recommended remediation for both developers and management.

SAMPLE FINDING Severity: high

Access to other customers' orders through the API

Affected asset
Orders API, endpoint /api/orders/{id}
Impact
An authenticated user changes an order number to read other customers' data.
Evidence
Reproduction steps and shortened request and response without sensitive data.
Recommendation
Verify record ownership on the server for every request.
Verification
Retest fixes within the proposal's agreed scope.
# logged in as account A
GET /api/orders/1044 HTTP/1.1
Authorization: Bearer ••••••••

HTTP/1.1 200 OK
{ "order": 1044, "owner": "account B" }

FROM FINDING TO PROTECTION

One application. Two perspectives.

Testing demonstrates how rules can be bypassed. The defensive perspective identifies where to stop that path and how to verify the fix.

Finding: access to other users’ data Remediation: authorisation checks

  1. Inputs and APIs

    A request arrives from an application or integration.

  2. Identity and permissions

    The server checks the user and their access to data.

  3. Services and logic

    Business rules determine which operations may proceed.

  4. Data and integrations

    Storage returns data within the permitted scope.

Authorised testing

Demonstrate the exploit path

In this example, a user accesses data belonging to someone else. The test provides evidence of the path, the missing control and the actual impact.

Targeted protection

Stop the unauthorised request

The server checks permissions before the request reaches data. A retest within the agreed scope can verify the effect of the fix.

Our process

From the first question to a usable result.

  1. 01

    Understand the situation

    What you want to find out or address, your environment and any constraints.

  2. 02

    Define the engagement

    Scope, rules, responsibilities and deliverables. Written authorisation for testing, a pilot for technology.

  3. 03

    Get to work

    We carry out the test, analysis or deployment. Critical findings are reported promptly as agreed.

  4. 04

    Deliver the results

    A management summary, technical details for your team and recommended next steps.

Frequently asked questions

What to know in advance.

Is testing legal and safe?

We test only with written authorisation and within an agreed scope. The rules specify authorised targets, techniques, timing, contacts and an immediate stop procedure.

Will we just receive a list of issues?

No. Every finding includes evidence, impact, priority and recommended remediation. Management also receives a summary, while the technical team receives the details.

Do we have to buy technology afterwards?

No. Test results are not tied to a product purchase. Any help with remediation or defence is agreed separately.

INITIAL CONVERSATION, NO OBLIGATION

Not sure where to start? Tell us what you are facing.

You do not need to know whether you need a test, a technology or a consultation. We will suggest a suitable next step based on your situation.

Arrange a consultation