Pith. sign in

REVIEW 4 major objections 5 minor 44 references

APIRL: Deep Reinforcement Learning for REST API Fuzzing

T0 review · 4 major / 5 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A deep reinforcement learning agent trained on one API can find more bugs in unseen REST APIs than state-of-the-art fuzzers, using fewer test cases.

desk verdict A genuinely new state representation for RL-based REST API fuzzing, but the headline bug-count claim rests on an undefined oracle for BitBucket and needs clarification before it can be accepted. read the letter →

arxiv 2412.15991 v1 pith:WH4QNFXX submitted 2024-12-20 cs.SE cs.AIcs.NI

Myles Foley , Sergio Maffeis This is my paper · ORCID
classification cs.SEcs.AIcs.NI
keywords RESTAPIfuzzingdeepreinforcementlearningQ-NetworkRoBERTatransformerembeddingblack-boxtestingHTTPstatuscoderewardmutation-basedbugdetection
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper tries to establish that a single deep reinforcement learning agent, trained once on one deliberately buggy open-source API, can mutate HTTP requests to find more server-side bugs in unseen real-world REST APIs than six established black-box fuzzers, while sending fewer test cases. APIRL frames REST API testing as a Markov decision process over a fixed 23-action mutation menu, and feeds the agent a state built from the API's JSON and natural-language response via a pre-trained transformer. The authors' central argument is that this response embedding gives the policy feedback that status codes alone cannot provide, which is what lets it generalise to endpoints it has never seen. If the claim is right, black-box API fuzzing becomes substantially cheaper: one pre-trained policy can be deployed directly on a new API instead of running per-API search heuristics. The paper also reports an ablation study showing that the choice of reward function and the transformer embedding both materially change the policy's behaviour.

What carries the argument

The load-bearing object is the transferable mutation policy: a Deep Q-Network over a fixed 23-action mutation space whose actions include authorisation-token changes, parameter switching, type changes, duplication, removal, file-extension appends, wildcards, default and related values, and admin flags. The state is a 772-vector formed by concatenating four functional features (HTTP method, HTTP response code, current parameter type, and normalised parameter index) with a 768-dimensional embedding from a RoBERTa transformer pre-trained by masked language modelling on 2,566 HTTP responses from 1,283 operations across 103 public APIs. The reward is the HTTP status code alone: +10 for a 5XX server error, +1 for a 2XX success, and −1 otherwise. The transformer embedding is the mechanism the paper credits for letting the agent read the content of responses, not just their status codes, and thereby generalise across endpoints.

What would settle it

Re-run the BitBucket experiments counting unique bugs per operation rather than by distinct source lines, since line attribution is impossible for that closed-source service; if APIRL's 6.6 bugs no longer exceed the attention-based baseline's 5.0 (or the ordering changes), the headline bug-count advantage is an artefact of the deduplication oracle.

Watch

Extended reading notes

Core claim

APIRL's central claim is that a Deep Q-Network, whose state concatenates four functional features with a 768-dimensional embedding produced by a RoBERTa transformer pre-trained on HTTP responses from 103 public APIs, learns a mutation policy that transfers to unseen endpoints. The policy is target-agnostic: the same state-action space applies to any OpenAPI-described REST API, so after training the agent runs black-box without further rewards or coverage feedback. In evaluation across 26 APIs and 823 operations, APIRL reports at least 6.4% more unique bugs than each of six baselines, with larger average margins, while using fewer requests than most baselines. Ablations attribute part of the gain to the transformer embedding: removing it reduces coverage by 8.4%, and feature-importance analysis ranks the embedded response features as the most influential input. A status-code reward that gives the largest incentive to 5XX responses outperforms coverage-based, uniform, ratio-based, and tabular-Q-learning reward variants.

Load-bearing premise

The headline comparison rests on the bug oracle: a 5XX response counts as a new unique bug only when it is attributed to a source line not seen before, and for closed-source BitBucket the paper gives no alternative deduplication rule, so the claimed margins presuppose that line attribution (or an unstated substitute) works consistently for every service under test.

Editorial extensions

If this is right

  • One policy trained on a single didactic API can be deployed black-box on unseen REST APIs without retraining or live coverage feedback.
  • Testing budgets shrink: APIRL finds at least 6.4% more unique bugs than each baseline while using fewer requests than most, and the per-request coverage efficiency is on average 64.8% higher.
  • The transformer's response embedding is doing real work: ablation shows an 8.4% coverage drop without it, and feature-importance analysis ranks embedded response features as the most influential state component.
  • Reward design materially changes the learned behaviour: a sparse status-code reward with a 5XX bonus outperforms coverage-based, uniform, ratio-based, and tabular-Q-style rewards, and a PPO variant falls into local optima, reinforcing the choice of DQN.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Editorial extension: a decisive test of the transfer claim would be to swap the RoBERTa embedding for a fixed non-contextual vector of the same length and measure the coverage and bug gap on the same 26 APIs.
  • Editorial extension: because the bug oracle counts 5XX responses by distinct source lines, the closed-source BitBucket numbers rest on an unstated deduplication rule; re-analysing that service by counting 5XX responses per operation would show whether the headline bug margin is robust.
  • Editorial extension: the paper's own limitation section notes that APIRL cannot add arbitrary key-value pairs beyond schema parameters; coupling the learned policy with a generative key-value proposal module is a natural extension that would likely recover the seven missed bugs the paper attributes to that restriction.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper proposes APIRL, a black-box REST API fuzzer based on Deep Q-Networks. The agent mutates HTTP request templates using a fixed action space of 23 actions, and its state representation combines four handcrafted request features with a 768-dimensional embedding produced by a RoBERTa transformer pre-trained on HTTP responses. The reward is primarily status-code-based, giving +10 for 5XX responses, +1 for 2XX, and -1 otherwise. The policy is trained on the Generic University API and then evaluated without further training on 26 APIs (823 operations), comparing against EvoMaster, RestTestGen, DeepREST, ARAT-RL, MINER, and a random-action variant. The main claims are that APIRL finds significantly more bugs than state-of-the-art tools while using fewer test cases, and that ablations show the value of the transformer embedding, the reward function, and the DQN choice.

Significance. If the main claims hold, APIRL is a useful contribution to black-box REST API testing: it packages a transferable RL policy with a pre-trained transformer feedback mechanism, and the evaluation is unusually broad for this line of work, covering 26 real-world APIs with five repetitions per experiment, an ablation over seven reward functions, an RL-algorithm comparison, and a SHAP-based feature analysis. The public release of the tool on GitHub is also a strength. However, the headline bug-count comparison is currently not fully interpretable because the unique-bug oracle for the closed-source BitBucket service is unspecified, and the claim that the policy generalizes to unseen APIs depends on the pre-training corpus not overlapping the evaluation services, which the paper does not explicitly establish. These issues are local and fixable, but they are load-bearing for the central claim.

major comments (4)
  1. [Section 5.2, Table 2] The paper defines a unique bug as a 5XX response whose originating source line differs from all previously counted bugs, but it also states that coverage cannot be collected for BitBucket because BitBucket is closed-source. Table 2 nevertheless reports BitBucket unique-bug counts for every tool, with no alternative deduplication rule stated for BitBucket. Because APIRL sends about 10,563 requests on BitBucket versus about 1,316 for EvoMaster, per-operation or response-text deduplication would not be comparable across tools. The 'at least 6.4% more bugs' claim in Section 5.4 is anchored to BitBucket (APIRL 6.6 vs EvoMaster 6.2), so the authors must either specify and validate a deduplication procedure for closed-source services, or exclude BitBucket from the bug-count comparison and re-derive the headline margin.
  2. [Section 5.1, Appendix C] The transformer is pre-trained on 2,566 HTTP responses from 103 REST APIs found on SwaggerHub, but the paper never states whether the 26 evaluation services (VAmPI, vAPI, c{api}tal, Spree, BitBucket, WordPress) were excluded from that pre-training corpus. The abstract and Section 5.4 claim generalization to 'unseen API endpoints'; this requires the evaluation services to be absent from pre-training, otherwise the measured transfer could partly reflect familiarity with the response structure of the test services. Please provide the full list of pre-training APIs or an explicit statement of exclusion.
  3. [Section 5.4] The textual percentage claims are inconsistent with Table 2. The paper states that EvoMaster and MINER find 117.6% and 99.2% fewer bugs than APIRL, respectively, but summing the per-service averages in Table 2 gives APIRL 34.5 bugs, EvoMaster 15.4, and MINER 16.65, which correspond to APIRL finding about 124% more bugs than EvoMaster and about 107% more than MINER. Likewise, 'at least 6.4% more bugs' appears to be computed from BitBucket (APIRL 6.6 vs EvoMaster 6.2), even though the best non-APIRL baseline on BitBucket is MINER with 6.3, a 4.8% margin. Please report the exact derivation of these percentages or replace them with effect sizes computed directly from the raw data.
  4. [Section 5.4, Table 2] The claim that APIRL finds 'significantly more bugs' is not backed by any statistical test. On BitBucket, APIRL's margin over EvoMaster is 0.4 bugs and its margin over MINER is 0.3 bugs, both smaller than the reported standard deviations (1.1 versus 1.3 and 1.5); on VAmPI and WordPress the differences from Rand-APIRL also overlap within one standard deviation. With five runs per tool, paired tests or confidence intervals should be reported for the headline comparisons, or the word 'significantly' should be replaced by a more cautious formulation.
minor comments (5)
  1. [Section 2.1] The sentence 'using semi-supervised approach the loss is computed... using the Bellmen equation' is imprecise: DQN training is better described as regression onto bootstrapped targets using the Bellman equation, and 'Bellmen' should be 'Bellman'.
  2. [Section 3, Figure 2] Figure 2 does not clearly show the feedback path from the HTTP response back to the agent, even though the text and reward definition rely on it; a loop arrow from 'HTTP response code / Coverage / Bugs' back to the state would improve readability.
  3. [Section 5.5, Table 3] The text says 'APIRL-cov finds the most bugs of the ablations (89% more than the next APIRL-cov variant)', but Table 3 does not contain a bug-count column, only error requests; please state explicitly that 'error requests' is the proxy used for bugs in this ablation.
  4. [Section 5.3] The sentence 'DeepRESTs multi-learning approach doesn't impact the rate of requests it can send as it achieves a high number of requests when testing endpoints' is unclear; if the intended meaning is that DeepREST is request-inefficient, please rephrase.
  5. [References] There are two Kim et al. 2023 entries in the reference list (the NLP-enhanced REST testing paper and the ARAT-RL paper); please disambiguate them with distinct citation keys in the text and bibliography.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: the RL policy is trained on Generic University and the transformer on separate API responses, while evaluation is on unseen services; no prediction reduces to a fitted input or self-citation.

full rationale

The paper's central claim (APIRL finds more bugs with fewer requests than six black-box baselines) is an empirical comparison on 26 REST APIs held out from training. The policy is trained on Generic University (Section 5.1) and the RoBERTa transformer is pre-trained on responses from 103 different REST APIs; the test services (VAmPI, vAPI, Capital, Spree, BitBucket, WordPress) are not used to fit any parameter. The reward Rsc (Eq. 1) and the evaluation oracle both use 5XX status codes, but this is metric alignment rather than circularity: training rewards raw 5XX responses, while evaluation counts unique bugs as 5XX responses originating from different source lines (Section 5.2), so the evaluation metric is not identical to the reward by construction. The only self-citations are (i) the curriculum-training design justified by (Wahaibi, Foley, and Maffeis 2023) in Section 5.1 and (ii) a related-work mention of (Foley and Maffeis 2022); neither is load-bearing for the headline result. A genuine validity concern, not a circularity concern, is that the unique-bug oracle requires per-source-line attribution that is impossible for closed-source BitBucket, and the paper does not state how BitBucket unique bugs were deduplicated; this affects interpretability of Table 2 but does not make the derivation circular.

Assumptions & free parameters 5 free parameters · 5 assumptions · 0 invented entities

The paper does not introduce new physical or conceptual entities. The main implicit assumptions are about the bug oracle, the representativeness of the training data, and the sufficiency of the action set. Hyperparameters and reward constants are hand-chosen or gridsearched, and the lack of a clear validation split is a mild concern.

free parameters (5)
  • DQN hyperparameters (gamma 0.9, alpha 0.005, batch size 128, update step 100, episode length 10, epsilon decay 0.999) = gamma=0.9, alpha=0.005, batch_size=128, update_step=100, episode_length=10, epsilon_decay=0.999
    Selected via gridsearch (Appendix B). The paper does not state whether the gridsearch used a validation set disjoint from the test services, so these may be tuned to the evaluation data.
  • Reward constants in Eq. 1 = +10 for 5XX, +1 for 2XX, -1 otherwise
    Chosen by hand to prioritize bug finding while providing dense feedback. Different constants would likely change the learned policy.
  • Test-time request budget = 3 episodes x 10 requests per operation = 30 max requests per operation
    Chosen in Section 5.2 to balance runtime and bug finding. This directly limits the number of test cases and favors efficient strategies.
  • Transformer pre-training hyperparameters (vocab 52k, batch size 64, epochs 10) = vocab_size=52000, batch_size=64, epochs=10
    Selected via gridsearch (Appendix B). These affect the quality of the response embedding and thus the state representation.
  • Unique-bug deduplication threshold = distinct source lines
    Defines the evaluation metric. For closed-source BitBucket this threshold cannot be applied, so the deduplication rule is ambiguous for that service.
assumptions (5)
  • domain assumption 5XX HTTP status codes indicate server-side bugs
    Used throughout as the reward signal (Section 4.4) and the primary evaluation metric (Section 5.2). Some APIs may return 5XX for expected error handling, which would inflate bug counts.
  • domain assumption Unique bugs can be counted by distinct source lines in every test service
    Stated in Section 5.2. For closed-source BitBucket this is impossible without source access, and the paper does not explain the workaround.
  • ad hoc to paper Pre-training the transformer on 2566 short HTTP responses yields a meaningful embedding
    Appendix C describes building a 52k-token vocabulary and performing masked language modeling on this small corpus. A RoBERTa-scale model trained from scratch on 2566 samples is unlikely to learn robust representations, but the ablation suggests it still provides some signal.
  • domain assumption Training on the Generic University API produces a policy that transfers to unseen APIs
    Section 5.1 trains only on Generic University. The claim of generalization is the empirical result, but it depends on the representativeness of this training environment.
  • domain assumption The 23-action mutation set is sufficient to expose bugs
    Section 4.2 fixes the action space. The paper acknowledges it cannot add arbitrary key-value pairs, which may limit bug discovery in some APIs.

how reviews work

0 comments
Cite this review

Pith. "Pith review of APIRL: Deep Reinforcement Learning for REST API Fuzzing." pith.science (2026). https://pith.science/paper/WH4QNFXX

@misc{pith2026241215991,
  author       = {Pith},
  title        = {Pith review of: APIRL: Deep Reinforcement Learning for REST API Fuzzing},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/WH4QNFXX}},
  note         = {Machine review of arXiv:2412.15991}
}
read the original abstract

REST APIs have become key components of web services. However, they often contain logic flaws resulting in server side errors or security vulnerabilities. HTTP requests are used as test cases to find and mitigate such issues. Existing methods to modify requests, including those using deep learning, suffer from limited performance and precision, relying on undirected search or making limited usage of the contextual information. In this paper we propose APIRL, a fully automated deep reinforcement learning tool for testing REST APIs. A key novelty of our approach is the use of feedback from a transformer module pre-trained on JSON-structured data, akin to that used in API responses. This allows APIRL to learn the subtleties relating to test outcomes, and generalise to unseen API endpoints. We show APIRL can find significantly more bugs than the state-of-the-art in real world REST APIs while minimising the number of required test cases. We also study how reward functions, and other key design choices, affect learnt policies in a thorough ablation study.

Figures

Figures reproduced from arXiv: 2412.15991 by the authors.

Figure 1
Figure 1. Part of the OpenAPI specification for VAmPI [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. The REST API testing process using APIRL. Godefroid, and Polishchuk 2019). From a specification, we extract the operations and their associated parameters. This forms a list of request templates (HTTP method, URL, parameters details) for the RL agent to mutate. For example, the operation in [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Improvements of APIRL compared to baselines. formance of APIRL results in higher efficiency of coverage per request, on average 64.8% higher. The lower standard deviation of APIRL further demonstrating the consistency in targeting mutations to improve over both Rand-APIRL and state-of-the-art. 5.4 Bugs Found and Request Volume We now investigate the ability to find bugs in the systems under test. APIRL outperforms a… view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: SHAPley Values for all features in descending or [PITH_FULL_IMAGE:figures/full_fig_p012_4.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

44 extracted references · 37 canonical work pages

  1. [1]

    JaCoCo Java Code Coverage Library

    2023. JaCoCo Java Code Coverage Library

    work page 2023

  2. [2]

    Adolphs, L.; and Hofmann, T. 2019. LeDeepChef : Deep Reinforcement Learning Agent for Families of Text - Based Games

    work page 2019

  3. [3]

    Arcuri, A. 2021. Automated Black - and White - Box Testing of RESTful APIs With EvoMaster . IEEE Software

    work page 2021

  4. [4]

    Atlidakis, V.; Geambasu, R.; Godefroid, P.; Polishchuk, M.; and Ray, B. 2020. Pythia: Grammar - Based Fuzzing of REST APIs with Coverage -guided Feedback and Learning -based Mutations . arXiv:2005.11498

    arXiv 2020

  5. [5]

    Atlidakis, V.; Godefroid, P.; and Polishchuk, M. 2019. RESTler : Stateful REST API Fuzzing . In 2019 IEEE / ACM 41st International Conference on Software Engineering ( ICSE )

    work page 2019

  6. [6]

    Barabanov, A.; Dergunov, D.; Makrushin, D.; and Teplov, A. 2022. Automatic detection of access control vulnerabilities via API specification processing. arXiv:2201.10833

    work page Pith review arXiv 2022

  7. [7]

    Bates, E.; Mavroudis, V.; and Hicks, C. 2023. Reward Shaping for Happier Autonomous Cyber Security Agents . In Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security , 221--232. Copenhagen Denmark: ACM. ISBN 9798400702600

    work page 2023

  8. [8]

    Böhme, M.; Pham, V.-T.; and Roychoudhury, A. 2016. Coverage-based Greybox Fuzzing as Markov Chain . In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security , CCS '16, 1032--1043. New York, NY, USA: Association for Computing Machinery. ISBN 978-1-4503-4139-4

    work page 2016

Show all 44 references
  1. [9]

    Böttinger, K.; Godefroid, P.; and Singh, R. 2018. Deep Reinforcement Fuzzing . In 2018 IEEE Security and Privacy Workshops ( SPW )

    2018

  2. [10]

    Caturano, F.; Perrone, G.; and Romano, S. P. 2021. Discovering reflected cross-site scripting vulnerabilities using a multiobjective reinforcement learning environment. Computers & Security

    2021

  3. [11]

    Corradini, D.; Montolli, Z.; Pasqua, M.; and Ceccato, M. 2024. DeepREST : Automated Test Case Generation for REST APIs Exploiting Deep Reinforcement Learning . ArXiv:2408.08594

    2024 arXiv

  4. [12]

    Corradini, D.; Zampieri, A.; Pasqua, M.; and Ceccato, M. 2022 a . RestTestGen : An Extensible Framework for Automated Black -box Testing of RESTful APIs . In 2022 IEEE International Conference on Software Maintenance and Evolution ( ICSME )

    2022

  5. [13]

    Corradini, D.; Zampieri, A.; Pasqua, M.; Viglianisi, E.; Dallago, M.; and Ceccato, M. 2022 b . Automated black-box testing of nominal and error scenarios in RESTful APIs . Software Testing, Verification and Reliability

    2022

  6. [14]

    Devlin, J.; Chang, M.-W.; Lee, K.; and Toutanova, K. 2019. BERT : Pre -training of Deep Bidirectional Transformers for Language Understanding

    2019

  7. [15]

    Foley, M.; and Maffeis, S. 2022. HAXSS : Hierarchical Reinforcement Learning for XSS Payload Generation . In IEEE 20th International Conference on Trust , Security and Privacy in Computing and Communications ( TrustCom )

    2022

  8. [16]

    Gage, P. 1994. A New Algorithm for Data Compression . C Users Journal

    1994

  9. [17]

    Godefroid, P.; Huang, B.-Y.; and Polishchuk, M. 2020. Intelligent REST API data fuzzing. In Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering

    2020

  10. [18]

    Kim, M.; Corradini, D.; Sinha, S.; Orso, A.; Pasqua, M.; Tzoref-Brill, R.; and Ceccato, M. 2023. Enhancing REST API Testing with NLP Techniques . In Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis , 1232--1243. Seattle WA USA: ACM. ...

    2023

  11. [19]

    Kim, M.; Sinha, S.; and Orso, A. 2023. Adaptive REST API Testing with Reinforcement Learning . ArXiv:2309.04583 [cs]

    2023 arXiv

  12. [20]

    Kim, M.; Xin, Q.; Sinha, S.; and Orso, A. 2022. Automated test generation for REST APIs : no time to rest yet. In Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis , ISSTA 2022

    2022

  13. [21]

    Lee, S.; Wi, S.; and Son, S. 2022. Link: Black - Box Detection of Cross - Site Scripting Vulnerabilities Using Reinforcement Learning . In ACM Web Conference

    2022

  14. [22]

    Li, X.; Liu, X.; Chen, L.; Prajapati, R.; and Wu, D. 2022 a . ALPHAPROG : Reinforcement Generation of Valid Programs for Compiler Fuzzing . In Proceedings of the AAAI Conference on Artificial Intelligence

    2022

  15. [23]

    Li, X.; Liu, X.; Chen, L.; Prajapati, R.; and Wu, D. 2022 b . FuzzBoost : Reinforcement Compiler Fuzzing . In Information and Communications Security : 24th International Conference , ICICS 2022, Canterbury , UK , September 5–8, 2022, Proceedings

    2022

  16. [24]

    Liu, Y.; Li, Y.; Deng, G.; Liu, Y.; Wan, R.; Wu, R.; Ji, D.; Xu, S.; and Bao, M. 2022. Morest: Model -based RESTful API Testing with Execution Feedback

    2022

  17. [25]

    Liu, Y.; Ott, M.; Goyal, N.; Du, J.; Joshi, M.; Chen, D.; Levy, O.; Lewis, M.; Zettlemoyer, L.; and Stoyanov, V. 2019. RoBERTa : A Robustly Optimized BERT Pretraining Approach

    2019

  18. [26]

    M.; and Lee, S.-I

    Lundberg, S. M.; and Lee, S.-I. 2017. A unified approach to interpreting model predictions. In Proceedings of the 31st International Conference on Neural Information Processing Systems , NIPS '17

    2017

  19. [27]

    Lyu, C.; Xu, J.; and Ji, S. 2023. MINER : A Hybrid Data - Driven Approach for REST API Fuzzing . In Proceedings of the 32nd USENIX Security Symposium

    2023

  20. [28]

    Martin-Lopez, A.; Segura, S.; Muller, C.; and Ruiz-Cortes, A. 2021. Specification and Automated Analysis of Inter - Parameter Dependencies in Web APIs . IEEE Transactions on Services Computing

    2021

  21. [29]

    McFadden, S.; Maugeri, M.; Hicks, C.; Mavroudis, V.; and Pierazzi, F. 2024. WENDIGO : Deep Reinforcement Learning for Denial -of- Service Query Discovery in GraphQL . In IEEE Workshop on Deep Learning Security and Privacy ( DLSP )

    2024

  22. [30]

    A.; Veness, J.; Bellemare, M

    Mnih, V.; Kavukcuoglu, K.; Silver, D.; Rusu, A. A.; Veness, J.; Bellemare, M. G.; Graves, A.; Riedmiller, M.; Fidjeland, A. K.; Ostrovski, G.; Petersen, S.; Beattie, C.; Sadik, A.; Antonoglou, I.; King, H.; Kumaran, D.; Wierstra, D.; Legg, S.; and Hassabis, D. 2015. Human-leve...

    2015

  23. [31]

    OpenAPI. 2023. OpenAPI Initiative

    2023

  24. [32]

    OWASP. 2023. OWASP API Security Top 10 2023RC

    2023

  25. [33]

    F.; Rae, J

    Parisotto, E.; Song, H. F.; Rae, J. W.; Pascanu, R.; Gulcehre, C.; Jayakumar, S. M.; Jaderberg, M.; Kaufman, R. L.; Clark, A.; Noury, S.; Botvinick, M. M.; Heess, N.; and Hadsell, R. 2020. Stabilizing Transformers for Reinforcement Learning . In Proceedings of the 37 th Intern...

    2020

  26. [34]

    Paxton-Fear, K. 2023. Generic University

    2023

  27. [35]

    Rethans, D. 2019. Xdebug - Debugger and Profiler Tool for PHP

    2019

  28. [36]

    Schaul, T.; Quan, J.; Antonoglou, I.; and Silver, D. 2016. Prioritized Experience Replay . arXiv:1511.05952

    2016 arXiv

  29. [37]

    Schulman, J.; Wolski, F.; Dhariwal, P.; Radford, A.; and Klimov, O. 2017. Proximal Policy Optimization Algorithms . arXiv:1707.06347

    2017 arXiv

  30. [38]

    Silver, D.; Huang, A.; Maddison, C. J.; Guez, A.; Sifre, L.; van den Driessche, G.; Schrittwieser, J.; Antonoglou, I.; Panneershelvam, V.; Lanctot, M.; Dieleman, S.; Grewe, D.; Nham, J.; Kalchbrenner, N.; Sutskever, I.; Lillicrap, T.; Leach, M.; Kavukcuoglu, K.; Graepel, T.; a...

    2016

  31. [39]

    S.; and Barto, A

    Sutton, R. S.; and Barto, A. G. 2018. Reinforcement learning: an introduction. Adaptive computation and machine learning series. Second edition edition

    2018

  32. [40]

    A.; Foley, M.; and Maffeis, S

    Wahaibi, S. A.; Foley, M.; and Maffeis, S. 2023. SQIRL : Grey - Box Detection of SQL Injection Vulnerabilities Using Reinforcement Learning . In Proceedings of the 32nd USENIX Security Symposium ( USENIX Security 23) , 6097--6114. ISBN 978-1-939133-37-3

    2023

  33. [41]

    Zheng, Y.; Liu, Y.; Xie, X.; Liu, Y.; Ma, L.; Hao, J.; and Liu, Y. 2021. Automatic Web Testing Using Curiosity - Driven Reinforcement Learning . In Proceedings of the 43rd International Conference on Software Engineering , ICSE '21

    2021

  34. [42]

    , " * write output.state after.block = add.period write newline

    ENTRY address archivePrefix author booktitle chapter edition editor eid eprint howpublished institution isbn journal key month note number organization pages publisher school series title type volume year label extra.label sort.label short.list INTEGERS output.state before.all...

  35. [43]

    write newline

    " write newline "" before.all 'output.state := FUNCTION n.dashify 't := "" t empty not t #1 #1 substring "-" = t #1 #2 substring "--" = not "--" * t #2 global.max substring 't := t #1 #1 substring "-" = "-" * t #2 global.max substring 't := while if t #1 #1 substring * t #2 gl...

  36. [44]

    write newline

    " write newline "" before.all 'output.state := FUNCTION fin.entry add.period write newline FUNCTION new.block output.state before.all = 'skip after.block 'output.state := if FUNCTION new.sentence output.state after.block = 'skip output.state before.all = 'skip after.sentence '...

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.