# Know which web and API weaknesses need fixing first. > Manual web and API penetration testing with Robert Ressl. Clear scope, reproducible findings, prioritized fixes and a focused retest. Safematix manually tests how users, browsers and API clients can cross access boundaries or misuse application workflows. Your team receives reproducible findings, a practical remediation order and a focused retest, within a written and explicitly authorized scope. ## A useful test starts with the decision your team needs to make. The assessment is a defined review of one application—not a claim to examine every system around it. It is useful when a release, access model or risk decision needs evidence that goes beyond a scanner result. ### Before a release changes access or behavior A new login flow, API, role or business function changes how people use the application. Safematix tests the agreed changes and relevant attack paths, giving engineering and release owners evidence about weaknesses that need attention before the next decision. ### When customers or roles share one platform Your application separates customers, teams or privilege levels. The assessment checks whether those boundaries hold on the server, not just in the interface, including attempts to access another user’s objects or invoke functions beyond an assigned role. ### When a findings backlog needs validation You have scanner output, reported issues or concerns that are difficult to prioritize. Safematix investigates the agreed application paths and records reproducible behavior, helping distinguish demonstrated weaknesses, relevant preconditions and practical impact from unverified alerts. ### When another party needs technical evidence A customer, procurement team or internal risk owner asks what has been tested and what remains open. A scoped report provides a traceable record of coverage, findings and retest outcomes without presenting penetration testing as a certification or legal assurance. ## Test the controls that separate legitimate use from abuse. Safematix combines manual investigation with supporting tools, working from the application’s roles, data and workflows. Coverage is risk-based and agreed in advance; a five-day package is not represented as an exhaustive review of every possible weakness. ### Authentication and session behavior Safematix examines login, session lifecycle, tokens and relevant browser/server trust boundaries. The work looks at how access is established, maintained and ended, including weaknesses that could let an attacker reuse a session or bypass an intended authentication step. ### API authorization and tenant separation Safematix checks whether object access and privileged functions are authorized for the actual requesting user. Testing follows relevant identifiers, roles and tenant boundaries, rather than assuming that hiding an interface element prevents the underlying API from being called. ### Business logic and workflow abuse Safematix examines agreed workflows for unsafe state changes, missing approval checks and misuse of role combinations. These tests ask whether individually valid requests can produce an unintended business result—questions that cannot be answered by a vulnerability scan alone. ### Input handling and deployment context Safematix follows relevant input paths, errors, configuration and secret-handling behavior where they affect the agreed application. Host or cloud settings are considered when they form part of that attack path; this does not turn the package into an unrestricted infrastructure audit. ## A report that supports fixes, ownership and verification. The output should help both decision-makers and developers act. It separates tested facts from assumptions, makes coverage limits visible and defines how a remediation result will be checked. ### Scope and coverage record A clear inventory of the application, API, roles, environment and agreed constraints. The record also identifies exclusions and relevant coverage limits, so later readers can tell what the assessment examined and avoid extending its conclusions to untested systems. ### Executive summary and priorities A concise explanation of the most relevant findings, affected business functions and remediation priorities. It gives non-specialist owners enough context to make decisions while retaining the preconditions and limitations that explain why a finding matters. ### Reproducible technical findings Each finding identifies the affected component, role, preconditions, expected behavior and observed behavior, supported by an appropriate request or harmless proof. Sensitive values are redacted, and the report distinguishes demonstrated impact from consequences that were not tested. ### Remediation backlog and debrief Findings include root cause, a practical remediation direction and a criterion for checking the fix. During the debrief, your team can clarify impact and ownership. Remediation development remains your responsibility unless a separate implementation scope is agreed. ### Focused retest and remaining exposure The package includes one focused retest within 30 days of the initial debrief, using the remediated build or configuration you supply. The result records fixed, partially fixed or open findings, updated evidence and any remaining exposure within the retested scope. ### Anatomy of a useful finding. Illustrative only—no client system, sensitive data, or real engagement detail. - **Endpoint:** GET /api/accounts/{id} - **Test:** Compare access for two authorized test users in different tenants. - **Evidence:** A user from tenant A requests a harmless object owned by tenant B. The API returns the object instead of 403 Forbidden. - **Impact:** Cross-tenant data exposure when server-side ownership checks are missing. - **Remediation:** Enforce tenant and object authorization on every request and add cross-tenant authorization tests. - **Retest:** Cross-tenant identifiers and variants are rejected, and automated authorization tests help detect regressions. ## Research and systems experience you can trace. Robert’s public research, credential links and systems background provide concrete evidence for a technical discussion. They do not substitute for the agreed scope, test access or evidence produced for your own application. ### Critical WordPress Core research Robert published a critical WordPress Core finding with root-cause analysis, reproducible laboratory evidence and a disclosure timeline. The write-up distinguishes local file inclusion from conditional code execution and documents deployment prerequisites rather than claiming that every installation was exploitable. [Read the WordPress research](https://ressl.ch/blog/cve-2026-87902-wordpress/) ### Publicly linked security credentials Robert’s public profile links credentials including OSWE, OSEP, OSCP and CISSP. These can be inspected individually rather than accepted as an uncheckable badge strip. They provide background; the application-specific report remains the evidence for what was actually tested. [View public credentials](https://ressl.ch/#career) ### Systems and deployment context Robert’s published background spans more than 20 years in systems, including Linux, high availability, cloud and offensive-security delivery. That background informs the examination of application behavior within its deployment and operational context, rather than treating an endpoint as an isolated target. [View Robert’s CV](https://ressl.ch/robert-ressl-cv.pdf) ## Agree the boundary. Test it. Explain it. Check the fix. Safematix works directly with your technical contact. Written authorization, a usable test environment and clear operational limits are part of the work—not assumptions left until testing begins. ### Define and authorize the test Safematix clarifies the application, API, business objective and up to two test roles. Together we agree environment, timing, permitted techniques, evidence handling and stop conditions. Written owner authorization and access readiness are confirmed before any testing takes place. **Deliverables:** - Written scope, targets and role inventory - Rules of engagement and authorization - Access, communication and escalation plan **Your responsibility:** Confirm ownership, provide agreed test accounts and available API or architecture documentation, and name a contact who can respond to operational questions. ### Investigate the relevant attack paths Safematix tests manually across the agreed roles, requests and workflows, using supporting tools where useful. Findings are validated with appropriate evidence. Testing stays within the authorized limits; load, stress or destructive techniques are not used without express authorization. **Deliverables:** - Test and coverage notes - Validated findings and reproducible evidence - Critical-finding notifications where applicable **Your responsibility:** Keep agreed access available, answer technical questions and communicate releases or environment changes that could affect the assessment. ### Report and plan remediation Safematix explains the findings to technical and business owners, with impact, root cause, remediation direction and verification criteria. The debrief helps your team set priorities and assign responsibility without confusing the assessment with an included development engagement. **Deliverables:** - Technical report and executive summary - Prioritized remediation backlog - Debrief and agreed verification criteria **Your responsibility:** Bring the people who can assess impact and implement fixes, confirm priorities and decide how to handle findings that remain open. ### Retest and record the result Your team supplies the remediated build or configuration for one focused retest within 30 days of the initial debrief. Safematix repeats the relevant checks and records the result. Additional targets, roles, findings coverage or retest rounds require a separately agreed scope. **Deliverables:** - Focused retest result - Updated finding status and evidence - Remaining-risk and next-action record **Your responsibility:** Implement the agreed fixes, identify the updated build or configuration and provide suitable access within the retest window. ## One application. A defined scope and a visible price. The Web & API Security Assessment costs CHF 9’800 for 5 working days. It covers one web application with its API and up to two roles, manual testing, a prioritized report, debrief and one focused retest. Additional targets or a broader infrastructure review receive a separately agreed scope. ### Web & API Security Assessment — CHF 9’800 5 working days Find exploitable weaknesses in one web application and turn them into prioritized, reproducible remediation. - One web application with its API and up to two roles - Manual testing, evidence, and prioritized report - Debrief and one focused retest within 30 days of the initial debrief, using the client-supplied remediated build or configuration **Not included:** - Load, stress, or destructive testing unless expressly authorized - Remediation development or additional targets and roles - More than one focused retest [Request package](https://safematix.com/?package=web-api-security#contact) Flexible engagements: CHF 2’200 per working day. Longer, clearly scoped remote projects: CHF 2’000–2’100. Short-notice OT, red-team, and high-security engagements: CHF 2’400–2’600, subject to scope. All package prices and day rates exclude applicable VAT and pre-approved travel and third-party costs, unless expressly included in the order form. Fixed-price packages apply within their stated scope. Scope, authorization, and start date are confirmed in writing before work begins. Regulatory mapping is technical, not legal advice. Savings and compliance outcomes are not guaranteed. ## What to clarify before the assessment starts. ### What does the fixed package cover? The Web & API Security Assessment is CHF 9’800 for 5 working days. Its boundary is one web application with the associated API and up to two roles. It includes manual testing, evidence, a prioritized report, debrief and one focused retest. Additional applications, targets or roles are not silently included; they need a separately agreed scope. ### What access and preparation do you need? Safematix needs written owner authorization, a technical contact, the agreed test accounts and any available architecture or API documentation. The scope also identifies the environment and important workflows. Credentials and sensitive technical material should be shared through the agreed secure channel, not included in the first contact-form message. ### How is this different from an automated scan? A scanner can help identify potential issues, but it does not fully understand your roles, ownership rules or business workflows. Safematix manually investigates the agreed paths and validates reportable behavior. The report explains prerequisites and impact instead of treating every tool alert as a confirmed weakness or claiming that a clean scan proves security. ### Can you test production without disrupting it? Production testing requires explicit agreement and a risk review. An equivalent staging environment is preferred when it provides the needed assurance. Rules of engagement define timing, limits, contacts and stop conditions. No test can promise zero operational risk, and load, stress or destructive testing is not performed without express authorization. ### Do you fix the issues, and what does the retest include? The package provides remediation guidance, not remediation development. Your team implements changes and supplies the updated build or configuration. One focused retest is included within 30 days of the initial debrief, checking the relevant findings and recording fixed, partially fixed or open status. Additional targets, roles or retest rounds are separately scoped. ### Will the report certify that our application is secure or compliant? No. It records the agreed scope, conditions, findings and limitations at the time of testing. It can support release, risk and customer discussions, but it is not a guarantee that every weakness has been found, a formal compliance certification or a legal opinion. Changes after testing may require additional review. ## Tell us what the application must protect. Describe the application, its users and the decision you need to make. We can then clarify the test boundary and the right starting point. A general overview is enough for the first enquiry; do not send credentials, production secrets or sensitive exploit details. [Discuss your application and test scope](https://safematix.com/?service=ethical-hacking#contact)