generated: '2026-09-07' method: probed source: live probes of /.well-known/security.txt on six hosts, plus a search of the AstrologyAPI site for a security, disclosure, trust or bug-bounty page, 2026-09-07 description: >- AstrologyAPI publishes no vulnerability disclosure channel of any kind. This artifact records that absence and one exposure found during enrichment, so the finding is not lost. program: present: false security_txt: false policy_page: false bug_bounty: false contact: null safe_harbour: null probes: - url: https://astrologyapi.com/.well-known/security.txt status: 404 - url: https://www.astrologyapi.com/.well-known/security.txt status: 404 - url: https://json.astrologyapi.com/.well-known/security.txt status: 404 - url: https://pdf.astrologyapi.com/.well-known/security.txt status: 404 - url: https://vision.astrologyapi.com/.well-known/security.txt status: 404 - url: https://mcp.astrologyapi.com/.well-known/security.txt status: 401 note: Authentication wall, not a served document. platforms_checked: - {name: HackerOne, result: not found} - {name: Bugcrowd, result: not found} - {name: Intigriti, result: not found} only_reporting_route: channel: General contact form / support email urls: - https://astrologyapi.com/contact - https://astrologyapi.com/contact-sales email: support@astrologyapi.com note: >- A researcher has no dedicated route, no PGP key, no stated response time and no safe-harbour statement — only the same form a sales enquiry uses. findings: - id: exposed-credentials-in-published-postman-collections severity: high status: unreported detail: >- Two of the eight Postman collections AstrologyAPI publishes for anonymous download embed a populated HTTP Basic auth block containing what appears to be a real account user ID and API key rather than a placeholder — the same pair in both files. The other six collections either omit auth or use the literal strings "user id" / "api key". Anyone who downloads the PDF collections receives working-shaped credentials. affected: - https://astrologyapi.com/postman/vedic_astrology_pdf_API_collection_postman_collection.json - https://astrologyapi.com/postman/western_astrology_pdf_API_collection_postman_collection.json observed: '2026-09-07' http_status: 200 handling: >- The collections were saved to postman/ in this repository for provenance and the credential values were replaced with REDACTED placeholders. Note that the pipeline secret sanitizer did NOT match this credential — it carries no vendor prefix and is shaped like ordinary text — so the redaction was applied explicitly rather than by pattern. The values were not exercised and are not stored in this repository. They remain live on the provider's own download endpoint. recommended_action: >- Rotate the exposed key pair and replace the auth blocks in both published collections with placeholders. This is exactly the kind of report a security.txt exists to receive, and its absence is why there is no route to send it. - id: oauth-metadata-malformed severity: medium status: unreported detail: >- Both OAuth discovery documents on mcp.astrologyapi.com emit the issuer with literal double-quote characters inside the value, producing unresolvable endpoint URLs and breaking RFC 8414 discovery for any strict MCP or OAuth client. See conformance/astrology-api-conformance.yml. affected: - https://mcp.astrologyapi.com/.well-known/oauth-authorization-server - https://mcp.astrologyapi.com/.well-known/oauth-protected-resource observed: '2026-09-07' assessment: >- No disclosure programme exists, so no Security pointer was added to apis.yml — the pointer would assert a channel the provider does not publish. Adding a /.well-known/security.txt with a contact address would be the single cheapest security improvement available to this provider, and the two findings above are the immediate reason it matters.