Method
How we test
ChikuOS audits are passive and owner-authorised. We look at what any visitor's browser receives from your live site (HTML, JavaScript, source maps, response headers, robots.txt and sitemap), measure speed with Lighthouse, and, for Supabase apps, check what your public anon key can read. A developer reads every result, proves each finding with the request or response that shows it, and ranks fixes by impact. We don't attack, load-test or sign in as other users. This page applies to the $49 AI Site Audit and the checks inside our other offers.
1. Permission first
We only check sites and apps you own or are authorised to have reviewed. You confirm that at checkout. If something we're asked to check clearly belongs to someone else, we stop and refund.
2. What we look at, and how
- Security from outside. Response headers (Content-Security-Policy, HSTS, frame and content-type options), HTTPS setup, a short list of commonly exposed paths such as
/.envand/.git/config(one ordinary request each), and your public JavaScript bundles and source maps for API keys,service_roleorsb_secret_keys and other secrets. - Supabase and Firebase access rules. Using only the public key your app already ships, we check which tables and storage buckets a signed-out visitor can read. We record counts or a column name as proof, not your users' data. We don't write, update or delete anything, and we never call database functions that could change data.
- Speed. Lighthouse on mobile and desktop, plus real-user Core Web Vitals from the Chrome UX Report where your site has enough traffic.
- SEO and AI visibility basics. Titles, descriptions, canonical tags, robots.txt, sitemap, structured data, social previews, and whether key content is in the HTML or only appears after JavaScript runs.
3. Tools
Lighthouse (Chrome DevTools or CLI), PageSpeed Insights, curl and browser DevTools for requests and headers, and plain text search of your built JavaScript. Dependency reviews use npm audit and Semgrep supply-chain results, read by hand. We don't run automated attack scanners against your site.
4. How findings are written
- Evidence. Each finding shows what we saw: the URL, the request and the response that proves it.
- Why it matters. In plain words, who could do what with it.
- Severity and rank. The top 10 fixes are ranked by impact, so you know what to do first.
- The fix. Exact steps, SQL or config, written so you or your AI coding tool can apply it.
See what that looks like in our sample report, which is a real check of this site.
5. What happens to your data
We keep the minimum needed to prove a finding. If we find a secret key in your front end, we tell you to rotate it and never use it. Reports are sent only to you, and we don't publish client names or results without permission.
Limits
An outside-in check can't see everything. Read what we don't check before you buy, so you know where a penetration test or a code review would fit better.