RepoVerse is a free tool that turns any public GitHub repository into an explorable 3D city in the browser. Folders become districts, files become buildings sized by how much code they hold, and the dependencies between them become the roads running from one to another. It runs on Three.js and needs no install and no signup for public repositories.

How does RepoVerse build a city from a repository?

It clones the repository, parses every source file into an abstract syntax tree, and reads the import statements to find what depends on what. That graph is laid out as a city: a folder becomes a district, a file becomes a building whose height is its line count, and each resolved import becomes a road. Git history is read in parallel, so how often a file changes and how recently are visible in the skyline rather than buried in a log.

Yes. Scanning public repositories, exploring the 3D city, sharing a link to one and the written summary every city carries are all free and need no account. A paid plan adds private repositories and the security review, which checks every declared dependency against the OSV vulnerability database and reads the repository's own source for hard-coded credentials, injectable queries and disabled certificate checks.

Which languages does RepoVerse support?

Python, JavaScript, TypeScript and TSX are parsed for functions, classes and imports. Go, Rust, Java, Kotlin, C#, PHP, Ruby, C++ and Swift are mapped as files and districts. RepoVerse can also scan a public website instead of a repository, returning its pages, scripts, stylesheets and the technologies it detects.

Does RepoVerse need access to my private code?

Not for public repositories — those are read anonymously and nothing is stored beyond the generated city. Private repositories need you to sign in with GitHub and grant access, and that token is used only to fetch the repository you asked for. The repository itself is never sent to a third party.

What is the metropolis?

The metropolis is a single 3D world holding every repository anyone has scanned. Each one owns the land around it, projects that share dependencies meet at a border, and the dependencies between them are roads with traffic moving along them. You can fly over it and walk into any city you find.

Is SameSite=Lax enough to stop CSRF?

It blocks cross-site POSTs in browsers that support it, which covers most attacks. Tokens are still recommended for older browsers and for flows SameSite does not cover, such as top-level GETs that change state.

How does RepoVerse detect missing CSRF protection?

It looks for cookie-based sessions with state-changing routes, no CSRF middleware and no SameSite setting, and lists the affected routes in the finding.

Türkçe

CSRF: requests your users never meant to send

Cross-site request forgery abuses the fact that browsers attach cookies automatically. Another site can make a logged-in visitor's browser submit a form to yours, and the session cookie goes along.

Example

Vulnerable

app.use(session({ secret: process.env.SESSION_SECRET }));

app.post("/transfer", isLoggedIn, (req, res) => {
  transfer(req.session.userId, req.body.to, req.body.amount);
  res.redirect("/account");
});

Fixed

app.use(session({
  secret: process.env.SESSION_SECRET,
  cookie: { secure: true, httpOnly: true, sameSite: "lax" },
}));
app.use(doubleCsrfProtection); // csrf-csrf, or lusca.csrf()

app.post("/transfer", isLoggedIn, (req, res) => { /* … */ });

How it happens

A page on an attacker's site contains a form that posts to https://your-site.com/transfer and submits itself on load. If your session cookie is sent on cross-site requests and the endpoint accepts any request carrying a valid session, the transfer happens. Cookie sessions without CSRF tokens and without SameSite are the classic setup.

How to fix it

Make a cross-site request unable to look like a real one.

Set SameSite=Lax (or Strict) on session cookies
Add CSRF tokens to state-changing routes (csrf-csrf, lusca, framework built-ins)
Never change state on GET requests
For APIs with token auth in a header, CSRF does not apply — cookies are the issue

How RepoVerse finds it

ModerateCookie sessions without CSRF protection
Another site can submit forms to state-changing routes on behalf of a logged-in user — the browser attaches the session cookie automatically.
data flow · CWE-352
LowSession cookie without SameSite
Browsers that do not default to `Lax` will attach the cookie to cross-site form posts, which is what a CSRF attack relies on.
website · CWE-1275

Questions

Is SameSite=Lax enough to stop CSRF?: It blocks cross-site POSTs in browsers that support it, which covers most attacks. Tokens are still recommended for older browsers and for flows SameSite does not cover, such as top-level GETs that change state.
How does RepoVerse detect missing CSRF protection?: It looks for cookie-based sessions with state-changing routes, no CSRF middleware and no SameSite setting, and lists the affected routes in the finding.

Updated 2026-10-11