OpenAI OpenAPI Project Scanner (OOPS)

• OpenAI OpenAPI Project Scanner (OOPS) is a comprehensive framework that automates RESTful API analysis, validation, and security assessment using OpenAPI Specification documents.
• It employs a modular pipeline combining static analysis, LLM-driven generation, and rule-based validation to improve API design quality and detect vulnerabilities like IDOR/BOLA.
• Empirical evaluations demonstrate high precision and recall in endpoint, parameter, and request/response inference across multiple programming languages and frameworks.

The OpenAI OpenAPI Project Scanner (OOPS) is a multi-faceted framework for automated processing, validation, and security assessment of RESTful APIs via OpenAPI Specification (OAS) documents. OOPS combines static analysis, property annotation, LLM-driven generation, and rule-based validation to address requirements in API documentation, interoperability, design quality, and security, notably the detection of access control vulnerabilities such as IDOR/BOLA. Recent evaluations demonstrate high precision and robustness across multiple programming languages and frameworks, facilitated by modular architecture and deep pipeline integration (Barabanov et al., 2022, Sundberg et al., 21 Nov 2025, Chen et al., 19 Jan 2026, Decrop et al., 2024).

1. Architectural Foundations and Modular Workflow

OOPS is architected as a layered pipeline with discrete but interoperable modules:

• OpenAPI Spec Parser: Processes JSON/YAML OAS files, recursively resolves $ref pointers, and builds a normalized AST for downstream analysis.
• Rule Engines: Dynamically load rule definitions (Python, YAML, or DSL) encompassing property validation, attack pattern matching, and domain-specific design constraints.
• LLM-Agent Workflow: Operates in two major phases—endpoint extraction and OAS generation. This combines file-level entry detection, API dependency graph construction, and multi-stage request/response inference executed by LLMs.
• Property Annotation and Attack-Group Mapping: Employs formal vectors (EP/OP/PP) for endpoints, operations, and parameters, systematically enabling vulnerability detection and feature-based pattern matching.
• Reporting & Integration: Aggregates findings in structured formats (JSON, JUnit XML, SARIF), supports runtime filtering/grouping, and provides CLI/IDE/plugin interfaces.
• Testing and Fuzzing Engines: Convert inferred specs into testing input for fuzzers (RESTler, EvoMaster), enabling black-box verification and error discovery (Barabanov et al., 2022, Sundberg et al., 21 Nov 2025, Decrop et al., 2024).

The architecture supports integration with CI/CD pipelines (e.g., GitHub Actions, Jenkins), local pre-commit hooks, and IDE plugins, with demonstrated runtime efficiency and feedback traceability.

2. Formal Definitions, Feature Annotation, and Rule Taxonomy

OOPS formalizes API elements using tuples and feature vectors, enabling precise analysis:

• Endpoint, Operation, and Parameter Properties:
  • $e = (path_e, M(e), EP(e))$
  • $m = (verb_m, P(e,m), OP(e,m))$
  • $p = (name_p, loc_p, schema_p, PP(e,m,p))$
• Attack-Group Feature Vector: $F(e,m)\in \{0,1\}^d$, capturing predicates over EP, OP, and PP vectors.
• Rule Taxonomy: 75 distinct design rules grouped into categories: URI structure, HTTP methods/semantics, operation identifiers, parameter design, pagination/filtering, versioning, error handling, schema/data model, security/authentication, documentation/metadata, caching/performance, and style/extensions (Sundberg et al., 21 Nov 2025).

Representative formalizations:

• Unique operationId:

$$\forall\, (p_1,m_1)\neq(p_2,m_2)\;\subset\;\mathrm{Paths}\times\mathrm{Methods}:\; opId(p_1,m_1)\neq opId(p_2,m_2)$$

• Required parameter description for deprecated elements:

$$\forall\,param \text{ s.t. } param.deprecated = \mathrm{true}:\; param.description \text{ contains "deprecated"}$$

This formalism enables rule engines to match patterns efficiently based on AST node types and property vectors.

3. Technology-Agnostic LLM-Based Specification Generation

OOPS employs LLM agents for automatic OAS inference and generation, independent of programming languages or frameworks (Chen et al., 19 Jan 2026, Decrop et al., 2024):

• Endpoint Method Extraction: Utilizes agents such as fileLevelAPIEntryDetector, fileDependencyAnalyzer, and endpointMethodExtractor to construct API dependency graphs and extract endpoint-method pairs.
• Multi-Stage OAS Generation: Separate agents (ReqSpecGen, RespSpecGen) generate parameters and response schemas. A self-refinement mechanism mitigates hallucinations (syntactic and semantic), employing iterative LLM calls to resolve JSON errors and specification upgrades.
• Prompt Masking Strategy: Applies masking tokens (e.g., <route>, <param>, <value>) and in-context LLM prompts to discover new routes, parameters, and valid values (Decrop et al., 2024).
• Specification Merging and Reference Reconstruction: Inline schemas are hashed and pooled, and Swagger 2.0 drafts are upgraded to OpenAPI 3.0.4.

Evaluations across 12 APIs spanning 5 languages and 8 frameworks report F1-scores of 98.8% for endpoint methods, 97.2% for request parameters, 97.0% for response inference, and 92.3% for parameter constraint inference (Chen et al., 19 Jan 2026).

4. Access Control Vulnerability and Non-Functional Quality Detection

A central capability of OOPS lies in detecting security vulnerabilities, notably Insecure Direct Object Reference (IDOR) and Broken Object Level Authorization (BOLA):

• Attack-Group Feature Vectors and Mapping: Patterns (e.g., "Enumeration without a priori knowledge", "Parameter pollution") are formally defined as Boolean conditions over features such as auth_required(e), has_id_in_path(e,m), num_id_params(e,m), and id_type.
• Detection Algorithm: Annotates properties, extracts feature vectors, and matches against a rule engine containing attack pattern formulas. Each match is logged with endpoint, method, parameters, and attack technique.
• Complexity Analysis: Parsing and feature annotation are $O(N \cdot M_{max} \cdot P_{max} \cdot D)$, with vulnerability matching $O(N \cdot M_{max} \cdot d)$ (Barabanov et al., 2022).
• Quality Rule Engine: Validates compliance with 75 design rules, producing actionable, traceable feedback and aligning API specs with enterprise governance requirements (Sundberg et al., 21 Nov 2025).

Empirical results show precision ≈ 0.89 and recall ≈ 0.87 for IDOR/BOLA vulnerability detection, with a false positive rate ≈ 0.11 (Barabanov et al., 2022). Design rule violation detection reports ≈ 85% actionable findings per scan and rapid execution times (Sundberg et al., 21 Nov 2025).

5. Evaluation Metrics, Empirical Results, and Error Discovery

OOPS modules are extensively evaluated via precision, recall, and $F_1$ formulas:

$$\mathrm{Precision} = \frac{TP}{TP + FP}, \quad \mathrm{Recall} = \frac{TP}{TP + FN}, \quad F_1 = 2 \times \frac{\mathrm{Precision} \times \mathrm{Recall}}{\mathrm{Precision} + \mathrm{Recall}}$$

• Security Scanning: Table-based results for IDOR/BOLA detection are presented for each test set with TP, FP, FN metrics (Barabanov et al., 2022).
• Design Rule Validation: OOPS catches all high-priority design issues in practitioner studies; precision and recall are both high (Sundberg et al., 21 Nov 2025).
• Automated Inference: Enumeration of correctly inferred routes and parameters; GET-route recall 85.05%, query-parameter recall 81.05% (Decrop et al., 2024); endpoint-method and parameter F1-scores exceed 97% (Chen et al., 19 Jan 2026).
• Error Discovery: Integration with black-box fuzzers (RESTler, EvoMaster) enables automatic bug candidate logging (e.g., server 5xx errors uncovered in 40% of tested APIs) (Decrop et al., 2024).

6. Integration into Development Workflows and Customization

OOPS is built for agile workflows, supporting CI/CD, IDE integration, and customization:

• CI/CD: Docker-based runners, GitHub/GitLab/Jenkins plugins, fail-on-error policies (Barabanov et al., 2022, Sundberg et al., 21 Nov 2025).
• Pre-Commit Hooks: Local scripts for YAML/JSON OAS file validation.
• IDE Plugins: VS Code and IntelliJ support for inline inspection and watch mode.
• Rule Set Customization: Domain-specific convention support via rule templates, severity remapping, contextual scoping, and batch toggling (Sundberg et al., 21 Nov 2025).
• Configuration and API-Key Management: Environment variable and JSON configuration per project, with rate-limit and concurrency control for LLM-based modules (Decrop et al., 2024).

Best practices include incremental rule adoption, verifiable configuration versioning, and integration of violation metrics into enterprise architecture dashboards.

7. Limitations, Base Model Sensitivity, and Future Directions

OOPS exhibits several known limitations and scopes for extension:

• Limitations: Dynamic endpoint registration and long regular expressions may elude static detection; LLM performance is base-model-sensitive; cost scales linearly with repository and endpoint size (Chen et al., 19 Jan 2026).
• Technology-Agnosticism: Confirmed on Go, Java, JavaScript, Python, PHP; no language-specific rules (Chen et al., 19 Jan 2026).
• Base Model Sensitivity: Gemini 3 Flash and GPT-5 mini outperform on different inference dimensions; smaller LLMs show F1 drops (Chen et al., 19 Jan 2026).
• Planned Enhancements: IDE integration, broader rule coverage, behavioral contract validation, multi-spec support (GraphQL, AsyncAPI), and integration with downstream LLM-driven testing agents are in project scope (Sundberg et al., 21 Nov 2025, Chen et al., 19 Jan 2026).
• Modular Extensibility: Plug-and-play support for LLM/fuzzer upgrades and custom oracles without redesigning the pipeline (Decrop et al., 2024).

This suggests OOPS will continue to evolve toward deeper workflow integration, comprehensive non-functional requirement coverage, and expanded technology reach.