Penetration test of off-chain systemsNot counted as an audit report
CertiK reviewed Swisscheese Finance (Swisscheese Finance - Pentest) on 15 May 2025: 6 findings, 1 critical; all marked fixed.
Report hosted on skynet.certik.com.
Trustblock does not review code.
Statuses are the security firm’s own, from its report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 1 |
| High | 0 | 0 | 0 |
| Medium | 0 | 0 | 3 |
| Low | 0 | 0 | 2 |
The endpoint `https://swisscheese.finance/api/swap/1inch?url=` performs an HTTP request to the user-supplied URL via the `url` parameter, allowing an attacker to make arbitrary requests from the server to both internal and external resources. Since the backend runs on an AWS EC2 instance, this vulnerability can be exploited to access internal metadata services, such as `http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance`. This endpoint exposes temporary AWS credentials assigned to the EC2 instance, which could allow the attacker to perform actions on the AWS environment depending on the attached IAM role. Additionally, when the SSRF targets an external URL, the backend includes the authorization token in the `Authorization` HTTP header.
The application does not properly validate or sanitize user input, allowing HTML and JavaScript code to be injected into various fields. While the Content Security Policy (CSP) currently in place blocks the execution of most injected JavaScript, this protection alone is not sufficient. Improperly handled input still creates a risk of cross-site scripting (XSS) in edge cases that bypass the CSP.
Improper handling of errors can introduce a variety of security problems for an application server. The most common one is the application return detailed stack traces, database dumps, and source code to the user when the server encounters an error. These messages reveal implementation details that should never be revealed. The web application returns a verbose error message exposing implementation details such as internal paths, packages used in the backend, and stack trace information.
The backend is using axios@1.5.1, which contains multiple publicly disclosed vulnerabilities that affect the security and integrity of the application. These include: * **CVE-2023-45857** – Cross-Site Request Forgery (CSRF) / Sensitive Cookie Exposure * **CVE-2025-27152** – Server-Side Request Forgery (SSRF) * **SNYK-JS-AXIOS-6144788** – Prototype Pollution * **SNYK-JS-AXIOS-6124857** – Regular Expression Denial of Service (ReDoS) For more information, please visit the following link: https://security.snyk.io/package/npm/axios/1.5.1
HTTP Strict Transport Security (also named HSTS) is an opt-in security enhancement that is specified by a web application through the use of a special response header. Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. It also prevents HTTPS click-through prompts on browsers. The server includes the `Strict-Transport-Security` header in HTTP responses, but it is misconfigured with a `max-age=0` value. This setting instructs browsers not to enforce HTTPS, effectively disabling the protection that HSTS is designed to provide.
The application uses the maximum possible value (`uint256` max) when calling the `approve` function for ERC-20 tokens in the Trade and ETF functionalities. This grants the smart contracts unlimited spending authority over the user’s tokens. While this approach may reduce the number of approval transactions and improve UX, it significantly increases the security risk by not limiting the scope or duration of token access.
The report names a repository or files. Open the report to see its scope.
1,044 projects reviewed · 1,375 reports · latest May 2025
See CertiK’s auditsSomething wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.
Tell us