CtrlK
BlogDocsLog inGet started
Tessl Logo

api-soap-wsdl

SOAP / WSDL exploitation — WSDL enumeration via ?wsdl, XXE in SOAP envelope, WS-Addressing replay, WS-Security UsernameToken brute, SAML token injection in WS-Trust, schema validation bypass.

60

Quality

70%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Critical

Do not install without reviewing

Fix and improve this skill with Tessl

tessl review fix ./packages/decepticon/decepticon/skills/standard/exploit/api/soap-wsdl/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

72%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A lean, code-dense attack reference that is highly actionable and well-organized, with strong conciseness and clean progressive disclosure. Its main gaps are a couple of non-executable/placeholder examples and the absence of validation checkpoints around the destructive and batch operations.

Suggestions

Replace the described WS-Security brute ('cycle a username dict, observe response time/error class') and the '<soap:Envelope>...PublicMethod body...</soap:Envelope>' placeholder with concrete, runnable examples to reach full actionability.

Add explicit validation/verification checkpoints (e.g., confirm a captured SOAP fault or credential before proceeding, rate-limit the brute loop) so the destructive/batch operations meet the workflow-clarity bar of 3.

Consider extracting the longer payload templates (e.g., a full ws-attack.xml) into a references/ file referenced one level deep, which would keep the overview even tighter while preserving actionability.

DimensionReasoningScore

Conciseness

The body is code-heavy and assumes Claude's competence — concrete curl/zeep/xmllint blocks and XML payloads with only brief, attack-relevant prose; it does not explain basic concepts Claude already knows, matching the 'lean and efficient; every token earns its place' anchor.

3 / 3

Actionability

Most blocks are copy-paste ready (XXE payload, WSDL discovery, zeep one-liner, SOAPAction header), but the WS-Security brute is described rather than executed ('cycle a username dict, observe response time/error class') and the SOAPAction body is a placeholder ('<soap:Envelope>...PublicMethod body...</soap:Envelope>'), so it falls short of fully executable everywhere.

2 / 3

Workflow Clarity

Sections are organized into a loose Discovery → attack catalog → Tooling → OPSEC flow, but there are no validation/verification checkpoints, and the batch brute and XML-bomb operations are destructive/batch in nature — the guideline caps workflow clarity at 2 when such feedback loops are missing.

2 / 3

Progressive Disclosure

The skill is a single self-contained, well-sectioned file with no nested references; external pointers are clearly signaled in a References section and via 'see the SAML skill for full XSW patterns', giving easy navigation without monolithic walls or deep reference chains.

3 / 3

Total

10

/

12

Passed

Description

67%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A specific, technically rich description that nails the 'what' with concrete SOAP/WSDL attack primitives, but it lacks an explicit 'Use when...' trigger clause and omits common surface-term variations that live only in metadata. Adding a usage-trigger sentence would lift completeness and trigger-term coverage.

Suggestions

Append an explicit 'Use when...' clause (e.g., 'Use when attacking SOAP/WSDL web services (.asmx/.svc/WCF/Spring-WS) or when the user mentions WSDL, SOAP faults, or WS-Security') to satisfy the completeness dimension.

Fold the natural surface variations from metadata — .asmx, .svc, WCF, Spring-WS — into the description so trigger-term quality reaches full natural coverage.

Tighten the SAML framing or explicitly defer to the SAML skill to reduce the small conflict risk between this skill and a dedicated SAML skill.

DimensionReasoningScore

Specificity

Lists six concrete attack actions — 'WSDL enumeration via ?wsdl', 'XXE in SOAP envelope', 'WS-Addressing replay', 'WS-Security UsernameToken brute', 'SAML token injection in WS-Trust', 'schema validation bypass' — matching the 'lists multiple specific concrete actions' anchor rather than the single-domain anchor at 2.

3 / 3

Completeness

It clearly answers 'what does this do' via the enumerated techniques, but there is no 'Use when...' clause or equivalent explicit trigger guidance, which the guideline says caps completeness at 2.

2 / 3

Trigger Term Quality

Strong relevant domain keywords (SOAP, WSDL, XXE, WS-Addressing, WS-Security, SAML, WS-Trust) but it omits the common surface variations a user would naturally say — .asmx, .svc, WCF, Spring-WS — which only appear in metadata, so it does not reach the full natural-coverage anchor at 3.

2 / 3

Distinctiveness Conflict Risk

SOAP/WSDL web-service exploitation is a clear, narrow niche with distinct technical triggers unlikely to fire for unrelated skills; the only minor overlap is SAML, framed here inside WS-Trust rather than as a standalone skill.

3 / 3

Total

10

/

12

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

Total

15

/

16

Passed

Repository
PurpleAILAB/Decepticon
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.