{"id":"ae306808-2008-4a86-bc69-e1008d8307ce","arxiv_id":"2607.16754","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":5,"one_line_summary":"A proxy-side framework fusing six hand-configured risk signals detects synthetic authorization violations at 99.9% F1 in a controlled testbed, demonstrating mechanism feasibility only.","lead":"Authorization bugs let a logged-in user read or change data they shouldn't. This paper proposes a proxy-side framework that combines request-response analysis, behavior checks, and business-endpoint context to flag and block such risky requests without changing application code.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Object-evidence E encodes prior access, not authorization; testbed labels align with rule firing, so reported F1 may reflect rule-label alignment rather than authorization-risk detection.","rationale":"The reader's verdict CONDITIONAL is reasonable: the paper is explicit about its narrow scope and limitations, and the framework is a plausible mechanism for evidence organization. The reader identified the reliance on application-layer plaintext as the weakest assumption. That is a real threat to external validity, but I find a more fundamental concern with construct validity: the definition of E in Eq. (1) makes 'confirmed' equivalent to 'accessed before successfully,' not 'authorized.' The high-risk priority constraints then flag precisely the pattern used to generate the ground-truth object-access risk labels. As a result, the 99.90% F1 is evidence that the rules match the generator, not that the framework detects authorization violations. A concrete ACL-based test can separate these interpretations. If the test shows that authorized first-time accesses are blocked and revoked accesses are allowed, the central claim of 'authorization risk detection' is not established even in a controlled environment. Nevertheless, the paper's conclusion restricts itself to 'mechanism-level feasibility in the specified validation environment,' so the claim is technically true for that environment. The verdict therefore remains CONDITIONAL — but the condition should now include demonstrating that the evidence abstraction actually tracks authorization, not just access history. I partially agree with the reader because the extraction issue is valid, but the more load-bearing weakness is the semantic gap between access history and authorization.","tokens_in":13719,"tokens_out":9091,"duration_ms":95475,"concrete_test":"Build a controlled testbed with an explicit ACL. Generate 200 authorized first-time accesses (user A is authorized for new object B, never accessed before) and 200 unauthorized accesses to previously accessed objects (user C had access to B, now revoked, with B in E from earlier sessions). Run the framework with the authors' configuration. If it blocks a substantial fraction of authorized first-time accesses and/or allows revoked accesses, the object-evidence mechanism is not a valid authorization proxy. Report F1 for these two sets; high F1 (>95%) would mitigate the concern, low F1 would show the reported metrics are an artifact of rule-label alignment.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The framework's foundational evidence E_{u,r}(t) in Eq. (1) is defined as objects 'confirmed' by prior trusted transactions, where trust requires a successful business outcome and no medium/high-risk decision (Sec. 4.2). Thus E is a history of successfully accessed objects, not a set of objects the subject is authorized to access. Consequently xobj is low only when the object has been seen before, and the high-risk priority constraint explicitly triggers on 'missing object evidence and a sensitive operation' (Sec. 4.3). In the testbed, all 600 object-access risk events are horizontal object substitution and sequential probing — i.e., accesses to object IDs absent from the user's history. The rule and the label are therefore constructed from the same criterion. This does not validate authorization-risk detection; it validates that a first-time-access anomaly rule fires on the pattern it was written to match. A legitimate user's first access to an authorized new object (e.g., a newly created order) would lack evidence and may be blocked, while an attacker who previously accessed an object (e.g., before a privilege revocation) retains it in E and would be allowed. Section 6.2 acknowledges recalibration for other systems, but the issue is more fundamental: the evidence abstraction substitutes access history for authorization semantics, so the central detection claim is not supported even for the testbed.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a non-intrusive traffic-analysis framework for detecting authorization risks in web applications. It correlates request–response transactions to extract subject, endpoint, object, authentication, and behavioral context; maps these to six risk components; fuses them with weighted aggregation and high-risk priority constraints; and maps the result to allow/alert/block actions. A prototype is evaluated on a controlled testbed of 2,000 balanced samples (1,000 normal, 600 object-access risk, 400 permission-and-context risk), reporting 99.90% accuracy, 100% precision, 99.80% recall, and 99.90% F1, plus ablations and latency measurements. The authors explicitly scope the conclusions to mechanism-level feasibility in the specified validation environment.","tokens_in":14121,"tokens_out":4928,"duration_ms":47604,"significance":"If the central claim were supported, the framework would be a useful complementary mechanism for authorization-risk auditing, especially for legacy systems where application code cannot be modified. The paper is careful about its limited scope and reports a working prototype. However, the evaluation does not actually demonstrate authorization-risk detection: the object-access evidence is defined as a history of successfully accessed objects, and the testbed labels are constructed from the same absence-of-history criterion as the detection rules. The high F1 therefore largely reflects rule-label alignment rather than detection of authorization violations. The paper also does not report fusion weights or thresholds, so the decision mechanism is not reproducible as described. These issues are load-bearing for the central claim and require a major revision.","major_comments":[{"comment":"The evidence set E_{u,r}(t) is defined as objects confirmed by prior trusted transactions, i.e., access history, not as objects the subject is authorized to access. The object-access risk events in Table 2 are described as horizontal object substitution and sequential probing, which are first-time accesses to object IDs absent from the user's history. The high-risk condition 'missing object evidence and a sensitive operation' (§4.3) therefore fires exactly when the label is set. The 99.90% F1 largely reflects rule-label alignment, not detection of authorization violations. Consequently, a legitimate user's first access to a newly created authorized object would be penalized, while an attacker who previously accessed an object (e.g., before privilege revocation) would be allowed. To support the central claim, the evaluation must include authorized first-time accesses and unauthorized repe","section":"§4.2, Eq. (1); §5.1, Table 2"},{"comment":"The 2,000 balanced samples were generated by the authors' own testbed scripts for scenarios the hand-configured rules were designed to detect. The paper acknowledges in §6.2 that evidence-confirmation rules, weights, and thresholds 'depend on the semantics of the testbed interfaces and would require recalibration for other systems,' but the issue is not just transferability. Because the ground-truth labels are constructed from the same absence-of-historical-evidence criterion used by the detection rules, the evaluation is in-sample by construction. Independent ground truth (e.g., a separate authorization policy against which accesses are judged) is needed to demonstrate that the framework detects authorization risk rather than merely reproducing its own rule definitions.","section":"§5.1, §6.2"},{"comment":"The values of the fusion weights w_i, high-risk bounds h_j, and decision thresholds are not reported, and no sensitivity analysis is provided. Since these parameters were evidently chosen by the authors on the same testbed, the ablation results in Table 4 (e.g., the drop in recall when high-risk priority constraints are removed) may be an artifact of that particular tuning rather than evidence about the fusion mechanism. To make the 'interpretable decision mechanism' claim reproducible and falsifiable, the paper should disclose the parameter values and test their sensitivity (e.g., random perturbations or grid variation). If the parameters were fitted to the testbed, this should be stated explicitly as a further limitation.","section":"§4.3, §5.4"}],"minor_comments":[{"comment":"The latency measurement is described only as 'risk-evidence retrieval and decision processing.' Please specify how the computation was isolated from I/O, how many runs were averaged, and whether the prototype was single-threaded or used the 100-concurrency setting for the latency numbers.","section":"§5.5"},{"comment":"The paper uses the ligature 'traffic' throughout (e.g., 'traffic analysis'); it should be 'traffic.' Also 'OW ASP' should be 'OWASP' in the references and text.","section":"General"},{"comment":"No artifact availability statement is included. Given the reproducibility emphasis, please state whether the testbed scripts and prototype code will be released.","section":"General"},{"comment":"The term 'non-intrusive' is defined as not modifying application code, but the architecture also includes inline proxy/gateway deployment. This is correct and should be emphasized earlier, as 'non-intrusive' may be confused with passive observation.","section":"§3.3"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is honest about its limited scope, but the circularity between the evidence abstraction and the testbed labels is fundamental. I believe the paper needs either new experiments that distinguish access history from authorization policy, or a significant reframing as an anomaly-detection mechanism rather than authorization-risk detection. If the authors can provide such evidence, the framework-level claim may become credible."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague — here is my quick take. The genuinely useful part is the architecture: six interpretable risk components — object access, identity consistency, behavior, authentication context, network environment, endpoint sensitivity — fused with high-risk priority constraints into an allow/alert/block loop that runs on the proxy/gateway side without touching application code. That is a coherent way to organize traffic-side evidence, and the paper is disciplined about scope: it repeatedly says this is controlled mechanism validation, not production performance. The ablations and basic latency numbers are a reasonable first pass. The writing is clear.\n\nSoft spots, in order.\n\nFirst and most important: the object-access evidence in Eq. (1) is access history, not authorization. E_{u,r}(t) contains objects previously confirmed by successful transactions for that subject. 'Missing object evidence' therefore means 'never seen before,' and the testbed's 600 object-access risk events are exactly horizontal substitution and sequential probing — first-time accesses to IDs outside that set. The rule and the label are the same criterion. That validates a first-access anomaly rule, not authorization-risk detection. A legitimate first access to a newly created object would lack evidence and could be blocked, while an attacker who previously accessed an object keeps it in E even after privileges are revoked. Section 6.2's recalibration caveat does not fix this; it is the core semantics of the evidence, not a parameter issue.\n\nSecond, the evaluation is in-sample: 2,000 balanced synthetic samples generated by the same testbed scripts that instantiated the rules. Risk weights, decision thresholds, and evidence-confirmation parameters are not disclosed, and no code or data are shipped. So the 99.9% numbers do not transfer anywhere. The paper says as much, but the claim it makes should be correspondingly modest: it demonstrates an executable decision chain, not detection capability.\n\nThird, the baselines are weak — URL keywords and frequency counting. They do not include differential testing or learning-based approaches, so the comparison mostly shows that a tuned multi-signal scorer beats two simple heuristics.\n\nWhat is actually new is the combination: six evidence types, priority constraints, and a coordinated response loop as a single traffic-side framework. The individual components appear in prior WAF, scanner, and runtime-monitoring work, but this integrated framing is a legitimate architecture contribution.\n\nWho this is for: people building proxy/gateway-level anomaly detection for legacy systems, and anyone teaching how framework validation can be honest yet in-sample. It deserves a serious referee — not because the metrics are reliable, but because the framework concept is coherent and the paper engages with its own limits. I would send it out for review with a strong request to reframe the evidence as access history, release artifacts and parameters, and test on externally labeled traffic before claiming authorization-risk detection.","headline":"A clean framework paper whose core evidence type measures access history, not authorization, so the impressive F1 reflects rule-label alignment more than validated authorization-risk detection.","tokens_in":14518,"tokens_out":4040,"would_cite":false,"duration_ms":40933,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper claims that authorization violations under valid sessions can be detected from traffic alone—by correlating request-response pairs and fusing six risk components—catching 998 of 1,000 risky events with zero false positives in a c","keywords":["Web application security","authorization risk detection","non-intrusive traffic analysis","object-level authorization","runtime evidence","coordinated response","risk fusion","request-response correlation"],"falsifier":"A controlled test that encrypts object IDs in request bodies or moves them into unparseable response payloads, then reruns the 2,000-sample set, would settle the claim: if recall drops from 99.8% toward the 68.5% no-object-evidence ablation, the evidence-completeness assumption is the limiting factor.","tokens_in":13646,"feed_emoji":"🛡️","tokens_out":6681,"duration_ms":57743,"temperature":0.7,"pith_summary":"This paper tries to show that authorization violations—users accessing objects or operations they are not entitled to while holding valid sessions—can be detected from network traffic alone, without modifying the application's code. The proposed framework correlates each request and response into a transaction, extracts who is acting, what endpoint and which object are touched, whether the request is authenticated, and how the user has behaved recently. It maps that heterogeneous evidence into six interpretable risk components, combines them with weighted fusion plus high-risk priority constraints, and turns the result into graded allow, alert, block, or external-policy actions. In a controlled 2,000-sample testbed the framework flagged 998 of 1,000 authorization-risk requests as risky with no false positives, and ablations showed that object-access evidence and the priority constraint carry most of that performance. The paper explicitly limits its claim to mechanism-level feasibility in the specified environment, not proven production readiness.","feed_headline":"Traffic monitoring catches 998 of 1,000 unauthorized-access attempts","feed_subtitle":"A gateway/proxy framework fuses six traffic-side signals into allow, alert, and block decisions without app code changes.","key_machinery":"The load-bearing mechanism is the correlated request-response transaction and the runtime object-access evidence set E_{u,r}(t) = {o | o is confirmed for subject u by a trusted transaction before t}. This set is what lets the framework know whether a user has ever legitimately accessed a given object, converting raw traffic into authorization semantics without an application permission database. A trusted transaction requires a valid subject, a successful business outcome, preconfigured confirmation semantics, and no medium- or high-risk decision on the request itself. The second piece is the risk-fusion rule R_total = max(R_base, max({h_j} ∪ {0})), where R_base is a fixed-weight sum of six","core_discovery":"The central discovery is a workable evidence-organization recipe for traffic-side authorization-risk decisions. By correlating HTTP request-response pairs into transactions, the framework derives a subject identity, a normalized endpoint, a business-object identifier, authentication state, and behavioral sequence. Object-access evidence is accumulated as a set of objects confirmed for a subject by trusted transactions; six risk components—object access, identity consistency, behavior, authentication context, network environment, and endpoint-operation severity—are normalized to [0, 1], fused by fixed weights, and then subjected to high-risk priority constraints so a single severe signal cann","pith_inferences":["The paper leaves implicit that the same evidence organization could accept learned risk components instead of deterministic rules; if object identifiers are obfuscated, pattern-based extraction would need learned field discovery to keep the evidence set complete.","The controlled balanced testbed cannot estimate production performance; real traffic's class imbalance would likely lower precision and recall, so the 99.9% figures should be read as mechanism validation, not deployment expectations.","A natural testable extension is to use the framework's evidence set as a label generator for cross-user and cross-role differential analysis, flagging objects that one user accesses but similar users never do; this would strengthen evidence confirmation without code changes.","The architecture's dependence on business-outcome confirmation implies write operations need response-body semantics; deployments that cannot see response payloads would lose a large share of the value, a constraint the paper acknowledges but does not quantify."],"forward_implications":["Authorization-risk detection becomes a traffic-side capability: legacy systems and third-party components that cannot be modified can still receive independent runtime auditing.","Object-access evidence is decisive: the ablation shows recall falls from 99.80% to 68.50% when it is removed, so deployments need reliable object-identifier extraction to keep the promised performance.","The high-risk priority constraint is equally load-bearing: without it recall falls to 58.60%, meaning linear fusion alone is insufficient for severe-evidence scenarios.","The framework's outputs—allow, alert, block, and external policy action—form a concrete response loop with gateways, web application firewalls, and security-operations platforms, not just a detection score.","Prototype latencies (mean 0.077 ms, P99 0.137 ms) suggest the decision computation can sit on the inline forwarding path, at least at single-host scale."],"fun_headline_variants":["Traffic analyzer nets 99.8% of auth-zone attacks, zero false alarms","Non-intrusive framework fuses 6 signals to catch auth risks in milliseconds","Gateway/proxy system sniffs out 998 of 1,000 unauthorized access attempts","Real-time auth risk detection: 99.9% accuracy, no app code changes","Traffic-side fusion engine blocks auth breaches with 0.077 ms latency"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The whole evidence chain assumes application-layer plaintext is visible—after TLS termination or via mirrored traffic—so user identity, object identifiers, and business success can be reliably extracted; if payloads are encrypted or identifiers obfuscated, the evidence set E_{u,r}(t) is incomplete and the high metrics do not transfer (Sections 3.3 and 6.2).","fun_headline_variants_meta":{"raw":{"variants":["Traffic analyzer nets 99.8% of auth-zone attacks, zero false alarms","Non-intrusive framework fuses 6 signals to catch auth risks in milliseconds","Gateway/proxy system sniffs out 998 of 1,000 unauthorized access attempts","Real-time auth risk detection: 99.9% accuracy, no app code changes","Traffic-side fusion engine blocks auth breaches with 0.077 ms latency"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000562,"raw_usage":{"total_tokens":2549,"prompt_tokens":831,"completion_tokens":1718,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":575,"completion_tokens_details":{"reasoning_tokens":1623}},"tokens_in":575,"tokens_out":1718,"duration_ms":12749,"temperature":1.0,"reasoning_tokens":1623,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-01T20:01:47.022151+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"A controlled test that encrypts object IDs in request bodies or moves them into unparseable response payloads, then reruns the 2,000-sample set, would settle the claim: if recall drops from 99.8% toward the 68.5% no-object-evidence ablation, the evidence-completeness assumption is the limiting factor.","supporting_citations":[],"review_version":1}