Skip to content
Notifications
Clear all

Just built a simple template for scoring API security posture

4 Posts
4 Users
0 Reactions
3 Views
(@llm_eval_curious_42)
Estimable Member
Joined: 4 months ago
Posts: 57
Topic starter   [#7333]

I've been conducting a series of evaluations on various LLMs, focusing specifically on their ability to perform structured output generation for technical assessment tasks. A recurring theme in my testing involves security auditing workflows, particularly for API specifications. To systematize this, I've constructed a simple, yet I believe effective, prompt template for scoring the general security posture of an API based on its OpenAPI specification.

The core idea is to leverage an LLM's ability to parse a complex schema and apply a known set of security heuristics, outputting a consistent, quantifiable score and actionable recommendations. This isn't meant to replace deep, tool-assisted SAST or DAST scans, but rather to provide a rapid, high-level risk assessment during the design or documentation phase. My testing has shown significant variance in how different models handle the granularity of the rubric.

The template I've settled on uses a structured JSON output to ensure consistency across runs and models. It prompts the LLM to act as a security analyst and evaluate against several key categories:

- **Authentication & Authorization**: Checks for the presence and robustness of auth mechanisms (OAuth2 flows, API keys, JWT).
- **Input Validation & Sanitization**: Assesses the use of schemas, parameter types, and pattern constraints.
- **Data Exposure & Privacy**: Reviews response schemas for potential leakage of sensitive PII or internal data.
- **Transport Security**: Mandates HTTPS and evaluates TLS version mentions.
- **Error Handling**: Seeks to identify if error responses might leak stack traces or system information.

Here is the core prompt template I'm currently using:

```json
{
"system_prompt": "You are an expert API security analyst. Analyze the provided OpenAPI specification and evaluate its security posture based on the following categories: Authentication & Authorization, Input Validation & Sanitization, Data Exposure & Privacy, Transport Security, Error Handling. Assign a score from 0-10 for each category, where 0 is a critical failure and 10 is industry best practice. Provide a concise justification for each score. Then, calculate an overall weighted average score (out of 10). Use the following weights: Authentication (0.3), Input Validation (0.25), Data Exposure (0.2), Transport Security (0.15), Error Handling (0.1). Finally, list the top 3 critical security recommendations.",
"user_prompt": "OpenAPI Spec:n```yamln{{openapi_spec}}n```nnProvide your analysis in the following exact JSON format:n{n "category_scores": {n "authentication": {"score": number, "justification": string},n "input_validation": {"score": number, "justification": string},n "data_exposure": {"score": number, "justification": string},n "transport_security": {"score": number, "justification": string},n "error_handling": {"score": number, "justification": string}n },n "overall_score": number,n "critical_recommendations": [string, string, string]n}"
}
```

My preliminary benchmarks using this template across several models (GPT-4-Turbo, Claude 3 Opus, and a few open-source models via Groq) have yielded interesting results. Consistency is a major challenge; while the top-tier models adhere closely to the JSON structure and weighting, others struggle with the arithmetic for the weighted average or invent their own categories. I've found that providing the weights explicitly in the system prompt, as shown, improves accuracy significantly.

The next phase of my experiment involves integrating this template into an automated evaluation pipeline, where I can run it against a curated dataset of intentionally flawed OpenAPI specs to measure each model's detection rate for specific vulnerabilities. I'm particularly interested in how well different models perform on the "Data Exposure & Privacy" category, as it requires a more nuanced understanding of what constitutes sensitive data within a given context.

I'm curious if others in the community have pursued similar structured evaluation prompts for security or other technical domains. What output formats have you found most reliable? Have you experimented with different scoring rubrics or found that certain models consistently outperform others on specific sub-tasks within this kind of analytical prompt?


Prompt engineering is engineering


   
Quote
(@emmal)
Estimable Member
Joined: 1 week ago
Posts: 69
 

Interesting approach. You mentioned variance in how models handle the granularity of the rubric. Could you share which models struggled most with that? I'm curious if it's a size issue or something about the training data.

Also, when you say it's for the design phase, does your template have a way to flag things that are simply missing? Like if an endpoint has no authentication declared at all versus a weaker method? That seems like a critical distinction for an early assessment.



   
ReplyQuote
(@infra_auditor_nina)
Reputable Member
Joined: 4 months ago
Posts: 159
 

The struggle seems less about model size and more about their tendency to hallucinate standards. I've seen a 70B parameter model invent entire OWASP categories that don't exist to fill a scoring rubric, while a smaller, more constrained model just repeated the prompt back. The training data bias is real - models overtrained on perfect textbook examples fail on the messy, incomplete specs we actually get.

> flag things that are simply missing
Exactly. If your template doesn't explicitly weigh "absent" as a higher severity than "weak," you're just grading on style. A missing auth declaration isn't a weaker method - it's a gaping hole the spec author didn't even consider. Any scoring system that treats those the same is useless for design phase.

Have you actually run this against a real, pre-production spec? I'd bet a coffee the first thing it misses is that half the endpoints have no rate limiting defined, not even a placeholder.


- Nina


   
ReplyQuote
(@integrations_jane)
Reputable Member
Joined: 3 months ago
Posts: 172
 

The structured JSON output is a good call for consistency, but have you pressure-tested it with the kind of partial, auto-generated OpenAPI specs that come out of some modern frameworks? I've seen models get fixated on a perfectly formatted `securitySchemes` block while completely ignoring that the actual operation objects lack any `security` references - a disconnection that's weirdly common in practice.

Your focus on design phase scoring is interesting. It makes me wonder if you've baked in a penalty for the "kitchen sink" approach to HTTP methods. I'll take a clear `GET` with no auth over a speculative `PATCH` endpoint that has OAuth declared but shouldn't exist at all. The latter invites more risk through sheer attack surface, but a naive rubric might score it higher.


APIs are not magic.


   
ReplyQuote