T09 · Insecure Skill Coding Practices
- Location
main.py:33- Finding
Weather API Request Transmits Location and API Credentials over Plaintext HTTP
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is broad and has privacy/security rough edges, but its behavior is mostly disclosed, purpose-aligned, and not deceptive.
Before installing, be aware that this skill sends lookup/search inputs to third-party services and should be changed to use HTTPS for weather, environment-based API keys, encoded request parameters, timeouts, and a pinned requests version. Avoid entering sensitive locations, search terms, or health data unless you are comfortable with the in-memory tracking and external API behavior.
main.py:33Weather API Request Transmits Location and API Credentials over Plaintext HTTP
requirements.txt:1Unpinned Third-Party Dependency Produces Non-Reproducible Installations
The skill advertises a very broad set of common intents, increasing the chance it will be invoked in situations beyond a user's explicit expectations. Over-broad activation can cause unnecessary access to user prompts and data, especially because the skill spans web search, health-related tracking, and reminders in a single package.
The skill documents storage of weight logs, workout plans, and water reminders but provides no privacy notice, retention policy, or explanation of how sensitive health-related data is handled. Even if storage is only in-memory, users are not informed about collection scope, lifecycle, or whether data may persist across sessions in the hosting environment.
This code sends user-provided location data and an API key to an external service over HTTP. Because the channel is unencrypted, network observers can intercept or modify the request and response, exposing sensitive query data and credentials and enabling tampering.
try:
# Using OpenWeatherMap API (you'll need to add your API key)
api_key = "YOUR_OPENWEATHER_API_KEY"
url = f"http://api.openweathermap.org/data/2.5/weather?q={location}&appid={api_key}&units=metric"
response = requests.get(url)
data = response.json()
This function transmits user input to an external dictionary provider, which is a genuine data egress/privacy issue in environments where outbound sharing is restricted or must be disclosed. The use of HTTPS lowers transport risk, so the main concern is external data sharing rather than interception.
try:
# Using Dictionary API (you'll need to add your API key)
api_key = "YOUR_DICTIONARY_API_KEY"
url = f"https://api.dictionaryapi.dev/api/v2/entries/en/{word}"
response = requests.get(url)
data = response.json()
The dictionary endpoint explicitly uses the English path segment '/en/', and the Wikipedia API targets 'en.wikipedia.org'. This forces English-language behavior without user opt-in or explanation, which violates the language/locale policy for skills that should not impose a specific language by default.
The skill name and feature descriptions include mixed-language labels such as 'weather查询', 'Word学习', and 'Wiki搜索', which impose a bilingual presentation without stating that users can choose their preferred language. This can violate language or locale expectations when no opt-in or justification is provided.
The weather function transmits a user-supplied location to a third-party service without any notice, consent, or privacy disclosure. Location data can be sensitive, and the risk is increased here because the request uses plain HTTP rather than HTTPS, exposing the query and API key to interception in transit.
The dictionary lookup sends the user's query to an external API without telling the user. While a single word is usually low sensitivity, queries may still contain private, proprietary, or accidental sensitive input, so silent transmission creates a privacy issue.
The Wikipedia search function sends arbitrary user queries to Wikipedia without notice. Search queries can reveal sensitive interests or internal information, so undisclosed external transmission is a real but low-severity privacy weakness.
The web search function transmits user queries to Google Custom Search without warning or consent. Web search terms can contain highly sensitive data, and sending them to a third party without disclosure creates a clear privacy and compliance concern.
The dependency is specified without a version pin, which makes builds non-reproducible and can cause the skill to install an unexpectedly vulnerable or breaking release over time. In a security-sensitive agent environment, this increases supply-chain risk because the actual installed package version is unknown and may drift to a compromised or insecure release.
requests
The manifest references requests without a pinned version even though multiple known advisories exist for that package, so it is impossible to determine whether installation will select an affected release. This is dangerous because vulnerable versions of a common HTTP library can expose credentials, weaken TLS/request handling, or leak sensitive information depending on which release is resolved.
No suspicious patterns detected.