As of 30 Oct 2026, Swisscheese Finance has 1 audit report on Trustblock, by CertiK, dated 15 May 2025. That report lists no open critical findings. It also holds 1 deployed contract on 1 chain.
Record last updated . It holds audits and findings, contracts and incidents up to Oct 2026. Trustblock does not review code.
Newest first
1 other security report listed, not counted
| Audit | Security firm | Date | Scope | Critical findings | Report |
|---|---|---|---|---|---|
| Swisscheese Finance - Pentest Penetration test of off-chain systemsNot counted as an audit report | Security firm: CertiK | Date: | Scope: Not recorded (see the report) | 1 critical finding, fixed | Open · skynet.certik.com |
| Swisscheese Finance - token audit | Security firm: CertiK | Date: | Scope: 1 address on Polygon (POS) | No open critical findings | Open · skynet.certik.com |
Statuses are the security firm’s own, from each report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 1 |
| High | 2 | 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.
Open the reportThe 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.
Open the reportImproper 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.
Open the reportThe 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
Open the reportHTTP 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.
Open the reportThe 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.
Open the report| Address | Chain | Source code |
|---|---|---|
| 0x3ce1…dce10x3ce1327867077b551ae9a6987bf10c9fd08edce1 | Chain: Polygon (POS) | Source code: Verified source |
Is this your project? Show this record on your own website. The label states what the record holds, links to this page and updates by itself. It is free and needs no sign-in.
Automatic: the three strongest facts of this project’s own record (its last audit and two more), highlighted. They update with the record. Picking a fact turns Automatic off.
<head><script src="https://widget.trustblock.run/project-widget.min.js" defer></script></head><body><divdata-tb-project-widgetdata-tb-project-slug="swisscheese"></div></body>
Paste the code where the label should appear. It uses no API credit and updates by itself.
Something 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