דוח לדוגמה, נתונים בדויים

הדוח לדוגמה כתוב באנגלית, כמו הדוחות שאנחנו מוסרים. אם תבקשו, נכתוב את הדוח שלכם בעברית.

Sample report, fictional data

External penetration test report

Wood & Thread, an online furniture store (fictional company)

Findings
Finding	Severity	CVSS score	Retest
F-01	High	7.1	Fixed
F-02	Medium	6.1	Fixed
F-03	Medium	5.3	Not fixed
F-04	Low	3.1	Inconclusive
F-05	Info	No score	Fixed

Report version: 1.1, including retest
System: Online store including its API
Test type: External penetration test, two user types, OSCP finding validation
Test window: 09:00 to 17:00, on the agreed days

Executive summary

We tested the Wood & Thread online store and its API from the outside, with a customer user and an admin user. We found five issues: one high, two medium, one low and one informational.

The most urgent is F-01: any logged-in customer can read other customers’ orders, including names and addresses. The fix is a targeted server change. F-03 comes next, because the admin panel is open to password guessing.

The retest found that three findings were fixed, one stayed open and one had an inconclusive result and will get another attempt.

Severity levels in the report and what to do with each
Severity	CVSS score	What it means for you
Critical	9.0–10.0	A weakness that could allow especially serious damage. Needs urgent attention.
High	7.0–8.9	A weakness with significant impact or potential for serious exploitation. Fix it soon.
Medium	4.0–6.9	A weakness that may affect the system or its users. Prioritize the fix according to the risk.
Low	0.1–3.9	A relatively low risk, but still check the context and the possible impact.
Informational	No score	Something worth knowing, such as details the server reveals unnecessarily. On its own it is not a weakness.

Scope

In-scope targets
Target	Address	Notes
shop.example	203.0.113.10	Public website and store
api.shop.example	203.0.113.11	Store APIs, as part of the system
shop.example/admin	203.0.113.10	Admin panel, admin test user

User types: customer, admin. Dedicated test users were provided by the client.

Out of scope: the external payment provider, the mailing system, the warehouse internal network and load testing.

Method and limitations

Testing was done from the outside with autonomous AI-based testing tools, at a limited rate and in the time window approved in writing. No actions changed real customer data.

Before delivery, MEIDAY went over the report to check that everything looks right. The OSCP add-on was ordered for this test: an OSCP-certified tester tried to reproduce each finding by hand, and the result is shown on every finding.

Limitations: source code, cloud configuration and business processes that need manual staff approval (such as refunds) were not tested. Autonomous testing can miss business-logic flaws. No finding in an area does not mean the area has no weaknesses.

Findings

F-01Access to another customer’s orders through the APIHigh7.1
F-02Reflected XSS in the search parameterMedium6.1
F-03No limit on login attempts to the admin panelMedium5.3
F-04The checkout page can be framed by another siteLow3.1
F-05The server discloses its software versionInfoNo score

F-01Severity: HighRetest: Fixed

7.1 CVSS 3.1

Component: GET /api/orders/{id} · api.shop.example
Classification: CWE-639
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N
Reproduction: Reproduced, 3 of 3 attempts

Access to another customer’s orders through the API

What we found

A logged-in user can read another user’s order by changing the order number in the URL. The server checks that the user is logged in but not that the order belongs to them.

Steps to reproduce

Log in as test customer A and open one of their orders. The request is GET /api/orders/10482.
Log in as test customer B in a separate browser session.
With customer B’s token, send the same request for order 10482.
The server returns 200 with customer A’s name, address and items. The expected response is 404.

Request and response (sensitive values redacted)

GET /api/orders/10482 HTTP/1.1Host: api.shop.exampleAuthorization: Bearer [customer B token] HTTP/1.1 200 OKContent-Type: application/json {"id":10482,"customer":"[redacted]","address":"[redacted]","items":[…]}

Business impact

Unauthorized access to other customers’ orders can expose names, delivery addresses and order details. How much is exposed depends on how many orders can be reached.

How to fix

In the order handler, look the order up by both its ID and the logged-in user’s ID, for example WHERE id = ? AND customer_id = ?.
If no order matches, return 404, the same response as for an order that does not exist.
Apply the same check to every endpoint that takes an order ID.
Add an automated test that logs in as one user, requests another user’s order and expects 404.

F-02Severity: MediumRetest: Fixed

6.1 CVSS 3.1

Component: GET /search?q= · shop.example
Classification: CWE-79
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
Reproduction: Reproduced in Chromium and Firefox

Reflected XSS in the search parameter

What we found

The search value is shown on the results page without proper HTML output encoding. A crafted link can run script in the browser of whoever clicks it.

Steps to reproduce

Open shop.example/search with a test value that contains HTML markup in the q parameter.
View the page source: the value appears inside <p>Results for: …</p> exactly as sent, without encoding.
The browser runs the script in the test value. This happened in Chromium and in Firefox.

Request and response (sensitive values redacted)

GET /search?q=[test payload redacted] HTTP/1.1Host: shop.example HTTP/1.1 200 OKContent-Type: text/html …<p>Results for: [payload appears here unencoded]</p>…

Business impact

An attacker who sends a customer a link can show fake content inside the site or act on their behalf while they are logged in.

How to fix

HTML-encode the search value before it is written into the page. Most template engines do this by default, so check that the results template does not turn it off.
Add a Content-Security-Policy header that blocks inline script, for example script-src 'self'.
Open the test link again and check that the value shows as plain text.

F-03Severity: MediumRetest: Not fixed

5.3 CVSS 3.1

Component: POST /admin/login · shop.example
Classification: CWE-307
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Reproduction: Reproduced, at the agreed low rate

No limit on login attempts to the admin panel

What we found

The admin panel is reachable from the internet and does not adequately limit password attempts, with no delay and no temporary lockout. We tested at a low rate in the agreed window, without guessing real passwords.

Steps to reproduce

Send a login request to /admin/login with the admin test user and a wrong password.
Repeat it 200 times from the same address, at the agreed low rate.
Every attempt gets the same response. No delay, lockout or CAPTCHA appears.

Request and response (sensitive values redacted)

POST /admin/login HTTP/1.1Host: shop.exampleContent-Type: application/x-www-form-urlencoded username=[admin test user]&password=[wrong password] HTTP/1.1 200 OK…<p class="error">Invalid username or password</p>… (Attempt 200 of 200 from 203.0.113.45: same response, no delay, no CAPTCHA)

Business impact

Admin passwords can be guessed without the system stopping it. A weak password could allow unauthorized access to the admin panel.

How to fix

Limit failed logins per address and per user, for example a growing delay after 5 failures and a 15-minute lockout after 10.
Turn on two-factor authentication for every admin user.
If the admins work from known addresses, allow the admin panel only from those addresses.
Log failed admin logins and alert on bursts.

F-04Severity: LowRetest: Inconclusive

3.1 CVSS 3.1

Component: /checkout · shop.example
Classification: CWE-1021
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N
Reproduction: Reproduced

The checkout page can be framed by another site

What we found

The page sends neither X-Frame-Options nor frame-ancestors, so another site can show it inside an iframe and hide a misleading layer over it.

Steps to reproduce

Create a test page on another domain that loads https://shop.example/checkout in an iframe.
Open the test page. The checkout page loads inside the frame and its buttons can be clicked.

Request and response (sensitive values redacted)

GET /checkout HTTP/1.1Host: shop.example HTTP/1.1 200 OKContent-Type: text/html(no X-Frame-Options, no Content-Security-Policy: frame-ancestors)

Business impact

A customer can be tricked into clicking a button on the checkout page without understanding what they are clicking.

How to fix

Add the header Content-Security-Policy: frame-ancestors 'none' to the checkout page, or list only the domains allowed to frame it.
Add X-Frame-Options: DENY as well, for older browsers.
Clear the CDN cache and check that the header appears on every response, including cached ones.

F-05Severity: InfoRetest: Fixed

No CVSS score (informational)

Component: All responses · shop.example
Classification: CWE-200
Reproduction: Reproduced

The server discloses its software version

What we found

The Server header returns the web server name and its exact version number.

Steps to reproduce

Send any request to shop.example.
The Server header in the response shows the web server name and its exact version.

Request and response (sensitive values redacted)

GET / HTTP/1.1Host: shop.example HTTP/1.1 200 OKServer: [server name]/[version]

Business impact

Version disclosure does not by itself indicate a vulnerability, but it can help identify versions with known vulnerabilities.

How to fix

In the web server settings, turn off the version number in the Server header.
Keep the server on a supported version and update it regularly.

Retest

The retest ran 21 days after the report, on the same findings and in the same scope.

Retest results
Finding	Severity	Status	Note
F-01	High	Fixed	In the retest the server returned 404 for every attempt to read another user’s order.
F-02	Medium	Fixed	The search value is now shown as text, with proper HTML output encoding. A CSP was added.
F-03	Medium	Not fixed	In the retest there is still no limit. Two-factor authentication was enabled, so the risk dropped, but the finding stays open.
F-04	Low	Inconclusive	The header was added in the test environment but did not appear on every response in production, probably because of caching. We will arrange one more attempt after the cache is cleared, at no cost.
F-05	Info	Fixed	The header now returns only the server name, without a version.

5 findings, 3 fixed on retest

Not fixedF-03 No limit on login attempts to the admin panel
InconclusiveF-04 The checkout page can be framed by another site
FixedF-01 F-02 F-05

External penetration test report · Wood & Thread, an online furniture store (fictional company) · Report version 1.1, including retest

Sample report, fictional data

רוצים לדעת כמה זה יעלה?

ממלאים ארבע שאלות קצרות במחשבון ומקבלים הערכת מחיר, כולל מע״מ.

למחשבון המחיר