@produtype/core 0.58.0 → 0.60.0

package/dist/analyzer/detectAuth.js

@@ -204,9 +204,20 @@ async function detectAuth(ctx) {
     const roleSignals = [...unambiguousRoles, ...comparedRoles].slice(0, 20);
     const permissionSignals = await (0, textSearch_1.searchInFiles)(ctx.root, sourceFiles, [/requirePermission/i, /permission_classes/i, /permissions\.py/i, /authorize\(/i, /\bcan\(/i], 20);
     const resourceLevelSignals = await (0, textSearch_1.searchInFiles)(ctx.root, sourceFiles, [
-        /requirePermission/i,
-        /permission_classes/i,
-        /authorize\(/i,
+        /**
+         * Per-record, which is what this capability claims.
+         *
+         * `requirePermission` and `permission_classes` were in this list, and they are
+         * checks on a route: the capability's own description is "per-record checks that
+         * a caller may act on the specific resource, **not just the route**". Three
+         * projects were credited with protection against reading another user's rows —
+         * one of them on the strength of `permission_classes = [AllowAny]`, a line that
+         * says the opposite. They belong to `authz.permissions`, where they already are.
+         *
+         * `authorize(` keeps its place but needs an argument. `google_calendar.authorize()`
+         * is an OAuth handshake, and it was standing in for an ownership check.
+         */
+        /\bauthorize\(\s*[^)\s]/i,
         /\bcanAccess\(/i,
         /\bhasAccessTo\(/i,
         /ownerId/i,
@@ -375,7 +386,9 @@ async function detectAuth(ctx) {
         },
         {
             key: 'authz.resourceLevel',
-            present: resourceLevelSignals.length > 0 || permissionSignals.length > 0,
+            // Route-level permission checks no longer stand in for per-record ones: with the
+            // needles above narrowed, this clause could only reintroduce what they removed.
+            present: resourceLevelSignals.length > 0,
             evidence: (0, absenceEvidence_1.evidenceOrSearch)(snippetEvidence(resourceLevelSignals), 'a check that the row belongs to the caller', ['requirePermission', 'permission_classes', 'authorize(', 'canAccess(', 'hasAccessTo(', 'ownerId', 'createdBy', 'req.user.id', 'userId ===']),
         },
         {

package/dist/analyzer/detectSecurity.js

@@ -135,6 +135,29 @@ async function detectSecurity(ctx) {
         (0, detectContext_1.hasDep)(ctx, 'slowapi');
     const rateLimitSignals = await (0, textSearch_1.searchInFiles)(ctx.root, source, [/rateLimit\s*\(/, /rate_?limit/i, /Retry-After/i, /\b429\b/, /TooManyRequests/i], 20);
     const rateLimit = rateLimitDep || rateLimitSignals.length > 0;
+    /**
+     * Rate limiting where the brute force happens.
+     *
+     * The rule is titled "Rate limit on auth surfaces" and its own passing sentence says
+     * "detected on the authentication surface", and the flag behind both was rate
+     * limiting *anywhere*: a limiter on a public feed cleared the check for a sign-in
+     * page that has none. Sign-in is the endpoint the limit exists for.
+     *
+     * The same file, which is as far as this reaches honestly. Where a project splits
+     * the limiter from the login the answer becomes "found, not shown to cover sign-in",
+     * which is true and which the reader can dismiss in two seconds if they know better.
+     *
+     * A prefix rule was written for this and removed. TranscribeAI protects its login
+     * with `app.use('/api/', limiter)` above `app.use('/api/auth', authRoutes)`, and
+     * matching the limiter's mount path against the auth router's looked like the right
+     * generalisation — but the mount line says `limiter`, not `rateLimit`, so no rate
+     * limit signal is ever on it and the rule never fired on the one case it was written
+     * for. Following the variable would work and is a third layer of guessing on top of
+     * two; TranscribeAI stays `partial`, which is what this can show.
+     */
+    const authSurfaceFiles = new Set((await (0, textSearch_1.searchInFiles)(ctx.root, source, [/['"`]\/(login|signin|sign-in|auth|session)/i, /passport\./, /signIn\s*\(/, /authenticate\s*\(/], 40))
+        .map((match) => match.file));
+    const rateLimitNearAuth = rateLimitSignals.some((match) => authSurfaceFiles.has(match.file));
     if (helmetDep)
         evidence.push({ type: 'dependency', value: 'helmet', claim: 'headers' });
     if (rateLimitDep)
@@ -253,6 +276,7 @@ async function detectSecurity(ctx) {
         details: {
             helmet,
             rateLimit,
+            rateLimitNearAuth,
             corsLoose: corsLoose.length > 0,
             corsStrict: corsStrict.length > 0,
             webhookSignature: webhookSig.length > 0,

package/dist/rules/rules.js

@@ -358,7 +358,18 @@ exports.rules = [
             const sec = analysis.detectors['security.core'];
             const hasAuth = Boolean(auth?.present);
             const hasRate = Boolean(sec?.details?.rateLimit);
-            const status = !isExpress || !hasAuth ? 'unknown' : hasRate ? 'passed' : 'missing';
+            /**
+             * Near the login, not merely somewhere.
+             *
+             * This passed on `rateLimit` alone, which is throttling anywhere in the
+             * repository — a limiter on a public feed cleared the check for a sign-in page
+             * that has none. The rule's own passing sentence says "on the authentication
+             * surface", and now it only says that when something shows it.
+             */
+            const nearAuth = Boolean(sec?.details?.rateLimitNearAuth);
+            const status = !isExpress || !hasAuth
+                ? 'unknown'
+                : nearAuth ? 'passed' : hasRate ? 'partial' : 'missing';
             return mkFinding({
                 id: 'security.rate-limit-auth',
                 title: 'Authentication rate limiting',
@@ -373,11 +384,13 @@ exports.rules = [
                  */
                 description: status === 'passed'
                     ? 'Rate limiting signals detected on the authentication surface.'
-                    : status === 'missing'
-                        ? 'No auth-focused rate limiting detected.'
-                        : !hasAuth
-                            ? 'Nothing here authenticates anybody, so there is no login surface to throttle.'
-                            : 'This check reads Express middleware, and this project does not use it — any throttling it has is somewhere this cannot see.',
+                    : status === 'partial'
+                        ? 'Rate limiting is in place somewhere, but nothing here shows it covering sign-in.'
+                        : status === 'missing'
+                            ? 'No auth-focused rate limiting detected.'
+                            : !hasAuth
+                                ? 'Nothing here authenticates anybody, so there is no login surface to throttle.'
+                                : 'This check reads Express middleware, and this project does not use it — any throttling it has is somewhere this cannot see.',
                 recommendation: 'Apply express-rate-limit (or equivalent) to login/register/password reset endpoints.',
                 /**
                  * The claim is about rate limiting, so the evidence is about rate limiting.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@produtype/core",
-  "version": "0.58.0",
+  "version": "0.60.0",
   "description": "Deterministic CLI and library that analyzes a web application repository and reports how far it is from production-ready for the kind of product it is meant to be.",
   "license": "MIT",
   "bin": {