Scan your app for security holes

In shortOpen Security and click Run security scan. In a minute or two MonstarX checks your code against 33 rules, probes the running app as a stranger, and has an AI read the whole app. You get a score from A to F and a list of findings, worst first, each with where it is, why it matters and what to change. Pick the ones to fix and MonstarX fixes them as a normal build, then scans again. You can download the result as a report.

Apps written fast tend to trust the browser too much: a function anyone can call, a booking looked up by its number without checking whose it is, a price taken from the page. Attackers look for exactly these gaps.

The Security tab reads your app the way an attacker would, lists what it finds with the worst first, and helps you fix it. Think of it as a small penetration test (a security check where someone tries to break in on purpose), built into MonstarX.

How do I run a security scan?

Open your project and click Security in the top bar.
Click Run security scan. It takes a minute or two.
Watch the three parts finish one after another. You can leave the tab: the scan runs on MonstarX’s servers and carries on. Cancel stops it and keeps what it found so far.

The Security tab’s badge in the top bar shows a spinner while a scan runs, then the number of open findings (coloured by the worst one) or a green dot when nothing is open. To scan again later, click Scan again at the top of the tab.

What does the scan check?

A scan has three parts:

Part	What it does	Cost
Code checks	33 rules run over every file of your app: missing sign-in checks, records changed without checking who owns them, secrets written into the code, database queries built from text, unsafe HTML, unchecked uploads, unverified webhooks and more.	Free
Live probes	Read-only requests against your running app as a stranger with no account: pages meant for signed-in people, routes that answer anyone, cross-site access, and, on a published app, security headers and files that should never be served.	Free
AI review	An AI model reads your whole app with the findings in hand, confirms them or rules them out, and looks for what only reading finds, like a price trusted from the page or data a page sends but never shows.	Uses credits, like a Chat request

Live probes use your published app when it is live, otherwise the preview. The result says which one it probed.

What are the OWASP Top 10 and CWE?

OWASP is a non-profit that publishes the Top 10, the best-known list of the most serious kinds of web app security risk. Every finding is filed under one of them, so you (or a security expert) know what kind of problem it is:

	In plain words
A01 Broken access control	Someone can see or change what is not theirs.
A02 Cryptographic failures	Secrets or codes are stored or made in a weak way.
A03 Injection	Text someone types is run as a command or code.
A04 Insecure design	The app’s logic can be abused, like unlimited free emails or bookings.
A05 Security misconfiguration	Settings are too open, like missing security headers.
A06 Vulnerable and outdated components	Old software with known holes.
A07 Identification and authentication failures	Weak sign-in or session handling.
A08 Software and data integrity failures	Code or data from outside is trusted without checking.
A09 Security logging and monitoring failures	Secrets leak into logs, or attacks go unnoticed.
A10 Server-side request forgery	The app can be made to fetch addresses an attacker chooses.

CWE (Common Weakness Enumeration) is a numbered catalogue of specific weaknesses, such as CWE-639: a record looked up by an ID the user controls. Each finding links to its OWASP category and, when it has one, its CWE page, so you can read more.

How do I read the results?

At the top you see a score out of 100 with a grade from A to F, the open findings by severity, what was scanned and probed, what the AI review cost, and the review’s summary in a few sentences.

Security scan results: grade C, 65 out of 100, 1 high and 4 medium findings, the AI review's summary, and the list of findings with their OWASP category, CWE and file

The score starts at 100 and loses 40 for each Critical finding, 15 for each High, 5 for each Medium and 1 for each Low. The grade says what to do next:

Grade	Score	Meaning
A	90–100	Nothing serious found.
B	75–89	A few things to tidy up.
C	55–74	Fix the high findings before more people use the app.
D	35–54	Serious gaps: fix them before publishing.
F	0–34	The app is open to attack as it stands.

Each finding shows its severity, title, OWASP category, CWE, where it came from (Code check, Live probe or AI review), how sure the scan is (Confirmed, Likely or Needs a look) and the file and line. Click one to open it:

An open finding: the code around the line, what is wrong, Why it matters, What to change, the AI review's note, and Open in Code, OWASP A04, CWE-770 and Set aside

The code around the line, with the line marked.
What is wrong, Why it matters and What to change, in plain words.
The AI review’s note: whether it confirmed the finding and how.
Open in Code jumps to the file in the Code tab.

When the AI review thinks a finding is a false alarm, it says AI review: probably not a real problem. That finding stays on the list, sorted last, but does not count toward the score.

Under the list, What was checked opens every check that ran, grouped by OWASP category, with a tick, the number of findings, or why it was skipped.

What was checked: 42 checks, 35 passed, 3 with findings, 4 skipped, grouped under A01 Broken access control, A02 Cryptographic failures, A03 Injection and A04 Insecure design

How do I fix what it found?

Tick the findings you want fixed, or click Select all. A Fix 2 findings button appears. It stays greyed out while a build is running.
Click it. MonstarX tells you what will happen, then click Fix 2 findings again.
Each finding becomes a task in your feature plan (Security: …; when the plan is nearly full, they share one task) and one build request goes to the chat, marked with a Security badge. It runs like any request, keeps a version, and QA may test the app afterwards.
When the build is done, the scan runs again by itself. Findings that are gone show as resolved (2 fixed by the builder). One that is still there comes back marked Still here after a fix.

What if a finding is not a real problem?

Open it and click Set aside, then say why:

Set aside as: Not a real problem, Accepted risk or Handled another way

Not a real problem
Accepted risk: you know about it and accept it.
Handled another way

A finding you set aside moves to the Set aside list and stays there in every later scan, even as other code changes. Click Bring back to put it on the list again.

How do I download the security report?

Click Download report at the bottom of the results. You get a Markdown file (a plain-text document that opens in any editor), named after your project, like paws-co-booking-security-report.md. It is shaped like a penetration test report:

Scope and method: how many rules ran over how many files, what was probed, and what the AI review did.
Summary: the score, open findings by severity and the review’s summary.
Findings: each with its OWASP and CWE links, where it is, the code, what is wrong, why it matters and what to change.
Resolved since the scan before, and Set aside by the owner, with your reasons.
Checks: every check with its result.

It is handy to share with a developer, a client or an auditor. The report is available once a scan has stopped running.

Frequently asked questions

Is a scan free?

The code checks and live probes are free. The AI review uses credits, like a Chat request, and the results show what it cost. Fixing findings uses credits like any build.

Does a good grade mean my app is safe?

No scan can promise that. It finds what its rules, probes and review can see. Fix the critical and high findings first, scan again, and have a person review anything that handles money or personal data before many people use the app.

Should I scan before or after publishing?

Both. Scan before you publish to catch the big holes. Scan again once the app is live: some checks, like security headers and files that should never be served, only run against a published app.

Can people I share my project with see the scan?

No. A scan names every weak spot, so only the owner sees the Security tab.

Does the scan check MonstarX's own sign-in and database code?

No. Those parts are the same in every app and maintained by MonstarX. The scan checks the code written for your app, and your running app.

What happens if a build is running when I start a scan?

The scan waits for the build to finish (up to 10 minutes), so it checks the finished code.

Automated QA testingTest that your app works in real browsers.

User accountsHow sign-in works in your app.

SecretsKeep API keys out of your code.

Publish your appPut your app online, then scan it again.