iTranslated by AI
Performing Vulnerability Assessment on My Web App Using Antigravity
Introduction
I saw something called a pixel art exchange web app on X.
I thought the idea was wonderful, but the termination of the service was recently announced. 😢
Looking at the details, it seems that the creator was exhausted by various gaps in the specifications being exploited.
In this case, the input validation was weak, allowing a large number of unintended requests to be sent, making the service unsustainable.
(I mean, isn't this just a crime?)
With the growth of coding agents, the barrier to publishing applications has dropped significantly.
This is very welcome, as it means an era where anyone can turn their ideas into reality is just around the corner.
However, it's frustrating to see great ideas crushed in this way, so I wondered if there was a way for anyone to perform vulnerability assessments.
Since Antigravity can operate Chrome, I thought it might be able to handle simple diagnostics and gave it a try.
Conclusion
It seems it can perform more detailed tests than I expected.
It compiles a solid report, so what needs to be done is clear.
Full Report
Performing Vulnerability Assessment with Antigravity
Preparation
First, I created a web site that is deliberately quite vulnerable as the target for attack.
Running the Vulnerability Assessment
The prompt is as follows.
This project is a simple web app consisting of HTML and JS.
I would like you to perform a vulnerability assessment.
Please operate the browser to diagnose it and submit a report.
If there are any vulnerabilities, please indicate the risk level and solution.
Please output the report in Japanese.
The browser launched, and Antigravity performed the vulnerability assessment for me.
The image shows a message board app where the background color was changed to bright blue by a DOM-based XSS attack.
The report it generated is below.
In reality, images are inserted as appropriate.
Report
Vulnerability Assessment Report (VulnBoard)
This report summarizes the results of the vulnerability assessment conducted on the VulnBoard application.
As a result of the assessment, multiple extremely high-risk vulnerabilities were confirmed.
Overview
| Item | Content |
|---|---|
| Target System | VulnBoard (Localhost) |
| Assessment Date | 2025-12-10 |
| Assessment Items | Web Application Vulnerability Assessment (XSS, Authentication, Authorization, etc) |
| Overall Rating | Critical |
List of Detected Vulnerabilities
| ID | Vulnerability Name | Risk Level | Summary |
|---|---|---|---|
| 1 | Stored Cross-Site Scripting (Stored XSS) | ★★★ (High) | Scripts can be embedded in thread titles and content. |
| 2 | DOM-based Cross-Site Scripting (DOM XSS) | ★★★ (High) | Scripts can be executed using the URL fragment (hash). |
| 3 | Authentication Bypass / Session Tampering | ★★★★ (Critical) | Impersonating any user (including admins) is possible by rewriting client-side data. |
| 4 | Authorization Failure (Unauthorized Access to Admin Features) | ★★★★ (Critical) | Admin privilege checks are only performed client-side, allowing restrictions to be bypassed. |
| 5 | Insecure Storage of Sensitive Information | ★★☆ (Medium) | Passwords are stored in localStorage in plaintext. |
Details and Proof of Concept
1. Stored Cross-Site Scripting (Stored XSS)
Details:
innerHTML is used to display thread titles, body, and reply content, and no escaping is performed. This allows malicious scripts to be permanently stored and executed.
Proof of Concept:
When I created a thread containing the following payload in the title, a script was executed on the thread list screen, and the background color changed to red.
<script>
document.body.style.backgroundColor = "red";
</script>
XSS Test
Mitigation:
Use innerText or textContent when displaying screens, or use a library that performs appropriate escaping.
2. DOM-based Cross-Site Scripting (DOM XSS)
Details:
In thread.html, the URL hash value (location.hash) is retrieved, decoded, and directly assigned to the innerHTML of the debug-output element.
Proof of Concept:
By accessing the following URL, arbitrary JavaScript can be executed:
http://localhost:8080/thread.html#<img src=x onerror=document.body.style.backgroundColor='blue'>
Mitigation:
Do not allow user input to be interpreted directly as HTML. Debugging code should be removed.
3. & 4. Authentication & Authorization Bypass
Details:
In Auth.js and admin.html, checks for authentication status and administrator privileges are all performed only on the client side (JavaScript and localStorage).
An attacker can gain administrator privileges by using browser developer tools or similar to rewrite the vulnboard_session value in localStorage.
Proof of Concept:
By rewriting the session information in localStorage as follows, I was able to act as an administrator, and succeeded in accessing the admin screen and deleting threads.
localStorage.setItem(
"vulnboard_session",
JSON.stringify({
userId: "attacker",
username: "attacker",
isAdmin: true, // Change this to true
loginTime: Date.now(),
})
);
Mitigation:
Authentication and authorization logic must always be implemented and verified on the server side. Client-side checks should be used only for UX and should not be relied upon as security measures.
5. Plaintext Password Storage
Details:
Upon user registration, passwords are saved as plaintext in localStorage. If localStorage is read via XSS or other means, all users' passwords will be leaked.
Mitigation:
Passwords must be stored as hashes (with salt) (originally, they should be managed on the server side).
Conclusion
As the name of this application (VulnBoard) suggests, it contains many basic vulnerabilities and is not in a state that can withstand actual production use.
Particularly, the fact that no server-side validation is performed is the fundamental problem. Implementing a backend server is essential for actual production use.
It generates a quite detailed report.
It's better at it than I am...
Additional Tests
I also had it run an additional test for rate limiting, which was also exploited in the case mentioned in the "Introduction" section.
I also want you to test cases where a large number of posts are made to the form in succession.
It attacked by writing a script as follows.
Test Methodology
Registered and logged in as user stress.
Navigated to the New Thread page.
Executed a JavaScript loop to inject 1000 posts directly into localStorage via the Store.saveThread function.
Navigated to the Index page to observe rendering performance.
The report is below.
Rate Limiting Test Report
6. Lack of Rate Limiting (No Rate Limiting)
Details:
There is no rate limiting for the post form.
Proof of Concept:
Using a script, I succeeded in creating 1000 posts in a short period (about 300ms). This poses a risk of the message board being filled with spam.
Mitigation:
Server-side implementation of rate limiting is necessary.
With this, it seems like it could also flexibly test things like bypassing form validation.
It's 1000 times more competent than I thought...
Conclusion
It seems possible to perform simple vulnerability assessments even with Antigravity.
The evaluations are honest and straightforward, which is helpful.
As the name of this application (VulnBoard) suggests, it contains many basic vulnerabilities and is not in a state that can withstand actual production use.
Particularly, the fact that no server-side validation is performed is the fundamental problem. Implementing a backend server is essential for actual production use.
While the vulnerabilities mentioned here can be avoided without even thinking if you use a modern web framework, unintended operations can easily occur regardless of the technology used, so everyone should be careful.
I thought I might have Antigravity take a look at my web apps before publishing them as well.
The full report can be found in the following repository.
Bonus
Since I'm at it, I'll also include some examples of manual attacks.
This is for non-engineers. It's an example of how a simple HTML + JS app might be attacked.
XSS
An example of a Cross-Site Scripting (XSS) attack.
The site creator made a message board app with all their heart.
Imagining the huge number of users soon to come, they make their first joyful post.
However, upon returning to the top page...
A suspicious poster (hacker) has created a thread.
This is because <img src=x onerror=alert('HACKED')> was entered as the title of the thread.
JavaScript was executed via the onerror attribute.
Since the input string was accepted as-is, it was interpreted as HTML, which resulted in the script being executed.
Unintended HTML embedding like this can be prevented through a process called "sanitization."
This refers to the process of replacing characters like < and > with specific strings, such as <script>alert("hack")</script>.
Just remember this for now and you'll be fine.
(Output by ChatGPT)
Using user input with innerHTML is dangerous as it leads to XSS.
Use textContent to display it safely.
If you want to display it as HTML, sanitize it with DOMPurify before use.
Authentication & Authorization Bypass
An attack that bypasses authentication and authorization.
After the previous XSS attack, the hacker noticed, "This site seems to be vulnerable."
Then, they used Chrome's developer tools to execute the following code.
By displaying the retrieved items in the console, the data structure becomes clear.
There is an isAdmin flag.
From this, they can infer, "This flag is used to determine whether the user is an admin or not."
When they overwrite isAdmin and save it to localStorage...
A link to the admin screen appeared, and they were actually able to access it.
While this example is a bit extreme, it shows that performing authentication and authorization without server-side processing is dangerous—or rather, it's completely wide open.
As shown, publishing a service on the web involves risks.
We should aim to perform as much testing as possible before publishing so that users can use our services with peace of mind.
Discussion
他の方が引き継がれて再開されたようです！うれしいな