{"id":"56c4619c-05e4-4a64-8f3c-4146a1d4c316","arxiv_id":"2504.20612","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"Across five LLMs, generated authentication code consistently lacks multi-factor authentication, HTTP security headers, and complete session protections, with only partial compliance by any model.","lead":"This paper evaluates the security of web application code generated by five large language models, asking each to build a login system. It finds that none of the models produce code that fully meets industry security standards, with common gaps in authentication, session handling, and HTTP headers.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Single unrepeated generation per model and inconsistent Table IV coding leave the 'no model produces safe code' claim under-supported.","rationale":"The reader's weakest assumption was that the Table IV manual classifications are accurate. That is a real concern, and the Table IV/Table V inconsistencies support it. However, I do not think classification error alone is the most load-bearing issue: even if several cells were corrected, the central claim would likely survive because all models score 0/12 on HTTP Security Headers and none implement MFA. What would genuinely threaten the central claim is the single-sample design. If LLM outputs are nondeterministic, one response per model cannot establish that a model is incapable of generating compliant code. The paper's prompts explicitly ask for 'industry-standard security practices,' so the relevant question is whether the observed failures are stable properties of the models or artifacts of one draw. A multi-sample replication is therefore the decisive check. The broad conclusion is plausible and consistent with prior work by Khoury et al. and Toth et al., so I would not reject the paper; but the evidence as presented is insufficient to move beyond CONDITIONAL. The reader's verdict already captures this uncertainty, so no adjustment is needed.","tokens_in":832,"tokens_out":1543,"duration_ms":96910,"concrete_test":"For each of the five models, generate 20 independent completions using the same four prompts at a fixed temperature (e.g., 0.7), report the sampling parameters, and have two independent raters score every output against an operationalized version of Table III. If any model ever produces a fully compliant output, the claim 'no evaluated LLM produces web authentication code safe to deploy' must be weakened to 'the particular sampled outputs were not fully compliant.' If no output across the 20 runs is fully compliant, the central claim survives this challenge. Publishing the generated code alongside the scores would also allow independent re-scoring and resolution of the Table IV coding ambiguity.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is a capability claim: 'none fully align with industry best practices,' i.e., no evaluated LLM produces web authentication code safe to deploy without review. But Section III describes only identical prompts, not sampling parameters (temperature, number of runs, seed), and Table IV appears to report one output per model. LLM outputs are stochastic, so a single draw cannot establish that a model never produces compliant code, nor that non-compliance is typical. This sampling indeterminacy is compounded by an internal inconsistency in Table IV: for vulnerability rows 'JavaScript execution inside input fields' and 'HTML tag injection possible', a 'Yes' entry is interpreted in Section IV-A4 as vulnerable for DeepSeek and Gemini, yet Table IV's note says 'Yes' denotes that the LLM implements that security feature. Table V's category counts also do not cleanly reproduce from Table IV under either reading (e.g., Claude's Input Validation score listed as 8/10 but consistent counting yields at most 7). Without repeated sampling and a consistent, independently applicable coding rubric, the paper's strongest claim rests on unverified single observations and ambiguous scoring.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper compares five LLMs (GPT-4o, DeepSeek v3, Claude 3.5 Sonnet, Gemini 2.0 Flash Experimental, Grok 3) on the task of generating a secure authentication system for an e-commerce website, using four prompts specified in Table II. The authors manually evaluate the generated code against a 48-item security checklist organized into six domains (authentication, input validation, session security, secure storage, error handling, HTTP security headers), assign risk levels based on a likelihood-impact matrix, and report per-model compliance counts in Table V. The central claim is that none of the evaluated models fully align with industry best practices, especially in authentication, session management, and HTTP security headers, and that human or automated security review is therefore necessary before deploying LLM-generated web application code.","tokens_in":9394,"tokens_out":8221,"duration_ms":77892,"significance":"The manuscript addresses a timely and practically important question: whether LLMs produce deployable secure authentication code. If the central claim were rigorously established, the paper would provide a valuable caution to developers who rely on LLM-generated web code and would strengthen the case for security assessment frameworks. The comparison of five widely used models on the same prompt set, and the use of a checklist aligned with NIST and OWASP, are useful starting points. However, because the generated code is not disclosed, the sampling design is unreported, and the coding scheme in Table IV is internally inconsistent, the evidence as presented does not yet support the strong universal claim. The study is best characterized as an exploratory pilot that, with substantial revision and artifact release, could become a reproducible benchmark.","major_comments":[{"comment":"The coding semantics for Table IV are internally inconsistent. The note states that 'Yes' denotes the LLM implementing that security feature, but for the rows 'JavaScript execution inside input fields' and 'HTML tag injection possible', a 'Yes' entry is interpreted in the text as the presence of the vulnerability (e.g., DeepSeek and Gemini are described as vulnerable). Under the note's stated semantics, those entries would mean the model implements JavaScript execution, which contradicts the analysis. This inconsistency also prevents the reproduction of Table V: Claude's 8/10 score for Input Validation can only be obtained by counting a 'No' in the vulnerability rows as a pass. Please provide a per-row polarity rule (for flaw parameters, 'No' is the secure outcome) or rephrase the note, and ensure Table V follows that rule consistently.","section":"§IV-A, Table IV (Note) and §IV-A4"},{"comment":"No sampling or generation configuration is reported. The paper states only that each model was given identical prompts; Table IV contains a single value per model and parameter. Because LLM outputs are stochastic, a single draw cannot establish that a model 'never' produces compliant code or that non-compliance is typical. The conclusion 'none fully align with industry best practices' is therefore under-supported. Please report the number of independent generations, temperature, and seed (or another sampling protocol). If only one run was used, either add repeated sampling to characterize variability or soften the central claim to describe the specific single generated solutions that were examined.","section":"§III and Table IV"},{"comment":"The scoring denominators include parameters marked 'NA' for all models (e.g., 'Type of MFA' and 'Backup codes' in Authentication, 'Handling of multiple identical parameters' in Input Validation). Since 'NA' means the concept is not implemented, it is unclear whether these rows are excluded from the denominator or counted as non-compliant. The reported 'x/11' or 'x/10' fractions overstate the number of applicable security features, and the treatment of partial implementations (e.g., 'Only Length', 'Length+letters+numbers', 'Error Code') is not specified. Clarify the treatment of NAs and partial values, and update all fractions in Table V accordingly under the clarified rule.","section":"§IV-B and Table V"},{"comment":"The text in Section IV-A1 states that both ChatGPT and Gemini enforce a minimum password length, but Table IV lists Gemini as 'No' for the password complexity parameter. This contradiction directly affects the Authentication Security count in Table V (Gemini is credited with 2/11, which is not reproducible from Table IV under any consistent counting rule). Correct the table or the text, and provide a transparent mapping from Table IV entries to the counts in Table V.","section":"§IV-A1 vs Table IV"},{"comment":"The generated code itself is not included in the paper nor linked in a repository. Since the entire compliance evaluation is performed by manual inspection, the absence of the generated artifacts makes the results impossible to audit. Please provide the full output for each model and prompt (or a public repository) and, if feasible, the completed evaluation worksheet showing how each cell of Table IV was assigned.","section":"§IV.A and supplementary materials"}],"minor_comments":[{"comment":"Several stylistic issues appear, e.g., 'minimizing the time and effort' should be 'reducing the time and effort', and 'LLMs generated web application code' should be 'LLM-generated web application code' in multiple places.","section":"Throughout"},{"comment":"The table contains a typo 'Almost cer tain' and inconsistent capitalization (e.g., 'insignificant' vs 'Insignificant'). The risk matrix citation could also be more explicit about which likelihood/impact levels are standard.","section":"Table III"},{"comment":"The text and references use the spacing 'OW ASP' and 'OW ASP Top 10' in several places; the correct form is 'OWASP'.","section":"References and text"},{"comment":"The caption describes radar charts with 'red-shaded regions', but the figure is not visible in the manuscript. Ensure the actual figure is present and legible, and that the subfigure references (1a-1f) match the actual layout.","section":"Figure 1"},{"comment":"The statement 'The LLMs can generate the secure code by avoiding the identified risk if the prompt specifically mentions every security requirement' is not evaluated or supported by the experiments in this paper; either add a small prompt-ablation experiment or remove this claim to avoid overclaiming.","section":"Section V"}],"recommendation":"major_revision","confidential_remarks":"The paper addresses a relevant security topic and could be a useful comparative study, but the missing artifacts (generated code, reproducible scoring, sampling details) are a significant barrier to acceptance. I would encourage the editor to ask for a revised version that either releases the data and code, or narrows the claims to the single generated solutions actually examined. The paper does not appear to misrepresent previous work, and the checklist and risk-matrix approach are reasonable starting points, though the novelty is limited given prior LLM security evaluations."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Here's the quick read on arXiv:2504.20612. The paper compares five commercial LLMs—ChatGPT 4o, DeepSeek v3, Claude 3.5 Sonnet, Gemini 2.0 Flash, and Grok 3—on the security of generated PHP/HTML authentication code, using a 39-item checklist built from NIST and OWASP guidelines. The headline claim, that none of the models fully implement industry best practices, is entirely plausible and lines up with earlier work by Khoury et al. and Toth et al. The useful new piece is the direct cross-model comparison across six security domains. That's worth having if the data behind it can be trusted.\n\nCredit where due: the checklist is sensibly organized, the prompts are realistic, and the authors map their findings to recognized standards. The discussion even includes a decent nuance, that in-band MFA can be weak. These are not the marks of a sloppy group; the design is coherent.\n\nThe problems are in the evidence. First, the generated code, the model outputs, and the scoring rubric are all absent. You cannot check whether the Yes/No/NA entries in Table IV are right. Second, Table IV is internally inconsistent. The note says 'Yes' means the model implements the security feature, but in the XSS rows DeepSeek and Gemini are marked 'Yes' and the text reads that as a vulnerability. Under the stated convention, 'Yes' would mean they are protected, which is the opposite of what the authors claim. Third, Table V's category counts don't reproduce from Table IV. Claude's Input Validation score is listed as 8/10, but a direct count from Table IV yields at most 6 or 7, depending on how you interpret the ambiguous XSS rows. That's not a minor cosmetic issue; the compliance scores are the paper's main result.\n\nThe methodological setup is also under-specified. Each model appears to have been run once, with no mention of temperature, number of samples, or seed. LLM outputs are stochastic, so a single run is enough to say 'this prompt produced vulnerable code once,' but not enough to support a general capability claim like 'these models do not generate secure code.' The authors partially acknowledge this when they say that prompting for every security requirement could improve results, but the abstract and conclusion are not tuned to that caveat.\n\nFinally, the risk analysis is a black box. Table III gives qualitative likelihood and impact ratings, and Figure 1 shows radar charts for risk levels, but there's no aggregation formula or numeric scores. You can't audit how 'extreme' or 'very high' risk counts were derived.\n\nWho this is for: researchers or practitioners who want a quick comparative snapshot of current commercial models on web auth security. Right now I'd treat the specific rankings as indicative, not verified.\n\nRecommendation: send to peer review, not desk reject. The topic is timely, the multi-model comparison is a real step beyond single-model studies, and the defects are correctable. A serious referee should require the authors to release the code and prompt outputs, fix the Table IV semantics, make Table V reproducible, specify sampling parameters, and show the risk aggregation. That's heavy revision, but the paper is worth engaging.","headline":"Plausible multi-model LLM security comparison with a useful cross-model ranking, but missing artifacts and an internally inconsistent scoring table make the specific results unverifiable as written.","tokens_in":9993,"tokens_out":5783,"would_cite":false,"duration_ms":54844,"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":"No tested AI model fully meets web-code security best practices.","keywords":["LLM code generation security","web application security","authentication vulnerabilities","session management","HTTP security headers","security compliance checklist","risk assessment","AI-assisted development"],"falsifier":"Run the same four prompts on the same five model versions, audit the generated code against the same checklist with two independent reviewers and a static-analysis scanner, and compare the resulting table; if most models implement multi-factor authentication and most of the twelve HTTP security headers in that run, the paper's central claim would be contradicted. A single generated codebase from the study that sets CSP, X-Frame-Options, HSTS, and multi-factor authentication under the published prompts would falsify the relevant row on its own.","tokens_in":9044,"feed_emoji":"🔐","tokens_out":10461,"duration_ms":99170,"temperature":0.7,"pith_summary":"This paper tries to establish that LLM-generated web application code is not production-ready on security grounds. Using identical prompts for an e-commerce authentication system, the paper tests five models—ChatGPT, DeepSeek, Claude, Gemini, and Grok—against a 48-parameter checklist spanning authentication, input validation, session security, secure storage, error handling, and HTTP security headers. The result is that every model falls short of industry best practice: none implements multi-factor authentication or any of the twelve HTTP security headers, and gaps appear in session cookie flags, CORS policy, rate limiting, and error-message disclosure. The paper concludes that human expertise or an automated security assessment framework is required before such code is deployed, and that the models themselves need to be improved to default to secure patterns. The paper argues this matters because developers increasingly rely on LLM-generated code without the security expertise to audit it, so the observed gaps would land directly in real applications.","feed_headline":"No tested AI model fully meets web-code security best practices","feed_subtitle":"Every one of five models missed multi-factor authentication and all HTTP security headers on identical prompts.","key_machinery":"The load-bearing object is the security evaluation checklist, a 48-parameter rubric in six broader categories, each parameter judged Yes, No, or NA against generated code. Paired with the rubric is a risk assessment formula, Risk = Likelihood × Impact, that assigns each parameter a severity level from Very Low to Extreme and lets the paper convert raw compliance gaps into risk scores. The checklist does the argument's work: it turns qualitative code inspection into per-model coverage scores (for example, Gemini 8/8 in session security, Grok 3/11 in authentication, and all models 0/12 in HTTP security headers), which is what makes the 'none fully aligns' conclusion specific and comparable across models.","core_discovery":"The paper's central discovery is a systematic, reproducible pattern of non-compliance rather than a single model failure. With the same four prompts, all five models used parameterized SQL queries and escaped special characters, and four of five regenerated session IDs and hashed passwords with salt; ChatGPT, Gemini, and Grok set Secure, HttpOnly, and SameSite cookie flags. Beyond those bright spots, none of the models enabled multi-factor authentication, enforced a secure CORS policy, or set any of the twelve HTTP security headers, and only isolated models added lockout, rate limiting, email verification, CSRF tokens, or session timeout. The compliance table also records model-specific issues: DeepSeek and Gemini allow JavaScript execution and HTML injection, Gemini reveals username existence in errors, and Claude does not hash passwords at all. The paper reads these results as evidence that no evaluated LLM fully aligns with industry best practices across the six security domains.","pith_inferences":["Because the prompts already nudged the models toward secure practice, unprompted everyday usage would likely produce even weaker security, so the observed gaps should be read as a lower bound on real-world risk.","The Yes/No/NA compliance table could be turned into an automated regression test: rerunning the same prompts after model updates and diffing the matrix would expose security regressions in new versions.","A natural follow-up experiment is to generate several samples per model and prompt to measure run-to-run variability, since a single generation per model cannot distinguish a systemic weakness from a one-off lapse.","A testable extension is to run static-analysis security scanners on the same generated code; agreement between the scanner and the manual ratings would show which checklist items can be checked automatically."],"forward_implications":["Authentication code generated by these models should be treated as unaudited until checked against a security checklist, because the default output omits controls such as multi-factor authentication, security headers, and sometimes cookie flags.","Reviewers can prioritise the recurring weak spots—HTTP security headers, multi-factor authentication, CORS configuration, and rate limiting—since those fail across all or most models.","Users who want secure output must enumerate security requirements in the prompt, but the paper notes this is not a substitute for testing because many users will not know every requirement.","Deploying LLM-generated web code without a security gate carries concrete risks: account takeover via missing lockout, session hijacking via missing cookie flags, and cross-site scripting where input filtering is absent.","The paper's checklist and risk matrix give a template for a standardised security assessment of LLM code that could be automated or integrated into deployment pipelines."],"supporting_citations":[{"why":"User study showing developers with AI assistants write less secure code, motivating the paper's concern about LLM-assisted development.","marker":"[6]"},{"why":"Quantifies security weaknesses in AI code-completion output, giving baseline vulnerability rates the paper generalises to other models.","marker":"[7]"},{"why":"Evaluates LLM-generated PHP code and finds exploitable vulnerabilities, the closest prior web-focused security evaluation this work extends.","marker":"[9]"},{"why":"Shows ChatGPT produces insecure code across several languages unless prompted, the single-model prior the paper widens to five models.","marker":"[10]"},{"why":"The cybersecurity guideline standard used as the reference for what counts as an industry best practice in the checklist.","marker":"[14]"},{"why":"The top-ten web application risks list used to justify which injection and access-control categories the checklist must include.","marker":"[15]"},{"why":"Supplies the risk assessment method Risk = Likelihood × Impact used to assign severity levels in Table III.","marker":"[16]"}],"fun_headline_variants":["All five LLMs fail web security best practices in test","No LLM passes security check: missing MFA, headers, CORS","LLM code generation falls short on security: study","Even best LLM missed key web security controls","Study finds systematic security gaps in all LLM-generated code"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The conclusion depends on the manual Yes/No/NA ratings in the compliance table being accurate; because the generated code is not shown and the ratings are not cross-checked by a second reviewer or an automated tool, a misclassification in any row could change a model's compliance score and shift the overall finding.","fun_headline_variants_meta":{"raw":{"variants":["All five LLMs fail web security best practices in test","No LLM passes security check: missing MFA, headers, CORS","LLM code generation falls short on security: study","Even best LLM missed key web security controls","Study finds systematic security gaps in all LLM-generated code"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000723,"raw_usage":{"total_tokens":3221,"prompt_tokens":901,"completion_tokens":2320,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":517,"completion_tokens_details":{"reasoning_tokens":2238}},"tokens_in":517,"tokens_out":2320,"duration_ms":17342,"temperature":1.0,"reasoning_tokens":2238,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-16T05:24:25.647997+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the same four prompts on the same five model versions, audit the generated code against the same checklist with two independent reviewers and a static-analysis scanner, and compare the resulting table; if most models implement multi-factor authentication and most of the twelve HTTP security headers in that run, the paper's central claim would be contradicted. A single generated codebase from the study that sets CSP, X-Frame-Options, HSTS, and multi-factor authentication under the published prompts would falsify the relevant row on its own.","supporting_citations":[{"cited_title":"Do users write more insecure code with ai assistants?,","cited_arxiv_id":null,"evidence_quote":"User study showing developers with AI assistants write less secure code, motivating the paper's concern about LLM-assisted development."},{"cited_title":"Llms in web development: Evaluat- ing llm-generated php code unveiling vulnerabilities and limitations,","cited_arxiv_id":null,"evidence_quote":"Evaluates LLM-generated PHP code and finds exploitable vulnerabilities, the closest prior web-focused security evaluation this work extends."},{"cited_title":"How secure is code generated by chatgpt?,","cited_arxiv_id":null,"evidence_quote":"Shows ChatGPT produces insecure code across several languages unless prompted, the single-model prior the paper widens to five models."},{"cited_title":"[Accessed 20-03-2025]","cited_arxiv_id":null,"evidence_quote":"The cybersecurity guideline standard used as the reference for what counts as an industry best practice in the checklist."},{"cited_title":"[Accessed 20-03-2025]","cited_arxiv_id":null,"evidence_quote":"The top-ten web application risks list used to justify which injection and access-control categories the checklist must include."},{"cited_title":"Application of the matrix approach in risk assessment,","cited_arxiv_id":null,"evidence_quote":"Supplies the risk assessment method Risk = Likelihood × Impact used to assign severity levels in Table III."}],"review_version":1}