@produtype/core 0.8.0 → 0.8.2

package/dist/analyzer/detectAuth.js

@@ -57,7 +57,24 @@ async function detectAuth(ctx) {
     ], 30);
     const twoFaSignals = await (0, textSearch_1.searchInFiles)(ctx.root, sourceFiles, [/two[_-]?factor/i, /otp/i, /totp/i], 20);
     const apiKeySignals = await (0, textSearch_1.searchInFiles)(ctx.root, sourceFiles, [/x-api-key/i, /apiKey/i, /API_KEY/, /token\s*scope/i], 20);
-    const passwordResetSignals = await (0, textSearch_1.searchInFiles)(ctx.root, sourceFiles, [/forgot\s*password/i, /password[_-]?reset/i, /reset\s*token/i], 20);
+    const passwordResetSignals = await (0, textSearch_1.searchInFiles)(ctx.root, sourceFiles, [
+        /forgot\s*password/i,
+        /password[_-]?reset/i,
+        /reset\s*token/i,
+        /**
+         * Django ships the whole flow — token, expiry, single use — behind one include.
+         * A report on a real school platform called password reset missing while
+         * `path("accounts/", include("django.contrib.auth.urls"))` sat in its urls.py:
+         * the words "password" and "reset" appear nowhere, because the framework
+         * supplies them.
+         */
+        /django\.contrib\.auth\.urls/,
+        /PasswordReset(View|ConfirmView|DoneView|CompleteView)/,
+        /auth_views\.PasswordReset/,
+        // The same shape in other frameworks that hand you the flow rather than the words.
+        /Devise|devise_for/,
+        /Auth::routes\(/,
+    ], 20);
     const emailVerificationSignals = await (0, textSearch_1.searchInFiles)(ctx.root, sourceFiles, [/verify\s*email/i, /email[_-]?verification/i, /confirm\s*email/i, /isEmailVerified/i], 20);
     const sessionSignals = await (0, textSearch_1.searchInFiles)(ctx.root, sourceFiles, [/session/i, /cookie/i, /jwt/i, /refresh\s*token/i, /httpOnly/i], 25);
     const roleSignals = await (0, textSearch_1.searchInFiles)(ctx.root, sourceFiles, [
@@ -83,6 +100,23 @@ async function detectAuth(ctx) {
         /organizationId/i,
         /tenantId/i,
         /workspaceId/i,
+        /**
+         * Django checks ownership inside the view, not in middleware before it.
+         *
+         * A report said "no resource-level authorization signals detected" of a codebase
+         * whose view reads
+         * `if not request.user.is_staff and request.user.pk != user.pk: raise
+         * PermissionDenied`, with visibility helpers called in every other view. The
+         * patterns above are all Express and DRF shaped, so none of that was visible.
+         */
+        /raise\s+PermissionDenied/,
+        /request\.user\.pk\s*!?==/,
+        /request\.user\.is_staff/,
+        /UserPassesTestMixin/,
+        /PermissionRequiredMixin/,
+        /@user_passes_test/,
+        /get_queryset\([^)]*\)[\s\S]{0,120}filter\([^)]*user/,
+        /\bis_visible_to\b/,
     ], 20);
     /**
      * Words that only mean tenancy, and words that usually mean something else.

package/dist/analyzer/detectUploads.js

@@ -44,7 +44,38 @@ async function detectUploads(ctx) {
         routeSignals.push(...findExpressUploadsRoutes(text, file));
     }
     const source = ctx.files.source;
-    const djangoPublicSignals = await (0, textSearch_1.searchInFiles)(ctx.root, source, [/MEDIA_ROOT/i, /MEDIA_URL/i], 15);
+    /**
+     * Django media served to the public, which is a route and not a setting.
+     *
+     * This matched `MEDIA_URL` and `MEDIA_ROOT` — two lines in settings.py that say where
+     * uploaded files live on disk and under which prefix they *would* be served. Neither
+     * serves anything. Django exposes them only when a URL pattern says so, and the
+     * idiomatic one is wrapped in `if settings.DEBUG`.
+     *
+     * A real report on a real school platform called its uploads publicly exposed on the
+     * strength of those two lines, with no pattern serving media anywhere in the project.
+     */
+    const djangoPublicSignals = await (0, textSearch_1.searchInFiles)(ctx.root, source, [
+        /static\s*\(\s*settings\.MEDIA_URL/i,
+        /document_root\s*=/i,
+        /re_path\s*\(\s*r?['"][^'"]*media/i,
+        /url\s*\(\s*r?['"][^'"]*media/i,
+    ], 15);
+    /**
+     * Django's own way of protecting a view: a decorator or a mixin, not middleware on a
+     * route. The Express-shaped route scan cannot see either, so a project whose upload
+     * view is `@login_required` read as having no protection at all.
+     */
+    const djangoProtectionSignals = await (0, textSearch_1.searchInFiles)(ctx.root, source, [
+        /@login_required/,
+        /LoginRequiredMixin/,
+        /PermissionRequiredMixin/,
+        /@user_passes_test/,
+        /@permission_required/,
+    ], 15);
+    for (const m of djangoProtectionSignals) {
+        evidence.push({ type: 'snippet', value: m.snippet, file: m.file, line: m.line });
+    }
     const validationSignals = await (0, textSearch_1.searchInFiles)(ctx.root, source, [/file-type/i, /mime/i, /content-type/i], 15);
     const protectedRoutes = routeSignals.filter((r) => r.protected);
     const unprotectedRoutes = routeSignals.filter((r) => !r.protected);
@@ -56,6 +87,7 @@ async function detectUploads(ctx) {
     for (const m of validationSignals)
         evidence.push({ type: 'snippet', value: m.snippet, file: m.file, line: m.line });
     const publicExposure = unprotectedRoutes.length > 0 || djangoPublicSignals.length > 0;
+    const protectedSomehow = protectedRoutes.length > 0 || djangoProtectionSignals.length > 0;
     return {
         key: 'uploads.exposure',
         present: uploadDeps.length > 0 || routeSignals.length > 0 || djangoPublicSignals.length > 0,
@@ -63,7 +95,7 @@ async function detectUploads(ctx) {
         evidence,
         details: {
             publicExposure,
-            protectedUploads: protectedRoutes.length > 0,
+            protectedUploads: protectedSomehow,
             protectedUploadsSameRoute: protectedRoutes.length > 0,
             unprotectedUploadRoutes: unprotectedRoutes.length,
             validation: validationSignals.length > 0,

package/dist/expectations/evaluateExpectations.js

@@ -96,7 +96,20 @@ function deriveStatus(analysis, capability) {
                 return 'present';
             if (loose)
                 return 'partial';
-            return 'missing';
+            /**
+             * A cross-origin policy is only a question for something that answers
+             * cross-origin requests.
+             *
+             * A server-rendered monolith with no API, no CORS library installed and no
+             * cross-origin handling anywhere is not missing a policy — the browser's own
+             * default already refuses those requests, and the absence *is* the safe
+             * configuration. Reporting it as a critical gap rewards adding middleware that
+             * can only loosen what is currently closed.
+             *
+             * An independent review of a report on a Django school platform put it as
+             * "not applicable, and inverted". It was right.
+             */
+            return servesCrossOrigin(analysis) ? 'missing' : 'not_applicable';
         }
         case 'security.rate-limit': {
             return boolDetail(sec, 'rateLimit') ? 'present' : 'missing';
@@ -275,6 +288,22 @@ function evidenceFor(analysis, capability) {
         .map((key) => detector(analysis, key))
         .filter(Boolean);
 }
+/**
+ * Whether anything here could receive a cross-origin request.
+ *
+ * An API surface, a framework built to serve one, or a CORS library someone installed
+ * on purpose. None of the three means the question does not arise.
+ */
+function servesCrossOrigin(analysis) {
+    // Somebody wrote cross-origin handling, however badly: the question plainly arises.
+    const sec = detector(analysis, 'security.core');
+    if (sec?.evidence.some((item) => /cors/i.test(String(item.value))))
+        return true;
+    // An API meant for other callers.
+    if (detector(analysis, 'auth.apiKeys')?.present)
+        return true;
+    return analysis.files.source.some((file) => /(^|\/)(api|routes?|controllers?|serializers?|graphql)(\/|\.)/i.test(file));
+}
 function evidenceQualityFor(detectors) {
     if (detectors.some((detectorResult) => detectorResult.evidence.some((item) => item.type === 'file' && typeof item.line === 'number'))) {
         return 'strong';

package/dist/rules/rules.js

@@ -1,6 +1,7 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.rules = void 0;
+const inferProductProfile_1 = require("../expectations/inferProductProfile");
 function statusFromFlags(present, complete) {
     if (!present)
         return 'missing';
@@ -204,7 +205,17 @@ exports.rules = [
                 category: 'security',
                 status,
                 severity: sevForStatus(status, 'medium'),
-                description: hasHelmet ? 'Helmet detected.' : 'Helmet/security headers not detected for Express app.',
+                /**
+                 * The description used to branch on `hasHelmet` alone, so a project that is not
+                 * an Express application at all — status `unknown` — still read "Helmet
+                 * detected." A Django repository was told that, which is a contradiction inside
+                 * one finding and exactly the kind of thing that costs a report its credibility.
+                 */
+                description: !isExpress
+                    ? `This check is about Express middleware; the backend here is ${analysis.stack.backend.join(', ') || 'not an Express application'}.`
+                    : hasHelmet
+                        ? 'Helmet detected.'
+                        : 'Helmet/security headers not detected for Express app.',
                 recommendation: 'Enable helmet() and review CSP/HSTS settings for your deployment model.',
                 evidence: det?.evidence ?? [],
             });
@@ -409,7 +420,22 @@ exports.rules = [
             // Tenant boundaries are a backend data-access concern: without a detected
             // backend the B2B keyword hint alone (e.g. in a frontend client) is noise.
             const backendDetected = analysis.stack.backend.length > 0;
-            const status = !b2bHint || !backendDetected ? 'unknown' : missingTenantRisk ? 'missing' : hasMembership ? 'passed' : 'partial';
+            /**
+             * And not when the product is not a business one.
+             *
+             * This fired on a school platform that the same report classified as a B2C app,
+             * so the document said "consumer application" in one place and "B2B/SaaS signals
+             * detected" in another. A reader cannot act on a report that contradicts itself,
+             * and of the two statements the profile is the one built from weighted evidence.
+             */
+            const consumerProduct = ['b2c-app', 'client-app', 'game', 'mobile-app', 'static-site'].includes(String((0, inferProductProfile_1.inferProductProfile)(analysis).inferredProfile));
+            const status = !b2bHint || !backendDetected || consumerProduct
+                ? 'unknown'
+                : missingTenantRisk
+                    ? 'missing'
+                    : hasMembership
+                        ? 'passed'
+                        : 'partial';
             return mkFinding({
                 id: 'tenancy.b2b',
                 title: 'Tenant and organization boundaries',

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@produtype/core",
-  "version": "0.8.0",
+  "version": "0.8.2",
   "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": {