Security at QA Workflow Assistant

Account and access security

QA Workflow Assistant supports Google sign-in and credentials-based authentication. Credentials-based accounts store hashed passwords. Authenticated sessions protect application routes, and API routes validate the session server-side. User-specific reads, updates, and deletes are scoped with ownership checks so one account cannot access another user’s records. Unauthenticated requests are rejected. Users can sign out at any time, and account deletion removes stored session records associated with that account.

Users are responsible for protecting access to their email and Google account, choosing a unique password for credentials-based sign-in, signing out from shared devices, and reporting suspected account compromise to info@qaworkflow.net.

Integration credential security

Jira and Xray integrations are optional. When configured, Jira API tokens and Xray client secrets are encrypted before database storage using authenticated encryption (AES-256-GCM). Encrypted values are versioned to support future migration. Credentials are decrypted only on the server when performing user-requested actions such as connection tests or push workflows. Stored secrets are not intentionally returned to the browser after saving.

Users can disconnect Jira or remove Xray credentials at any time. Account deletion removes stored integration credentials from the live application database. Previously created Jira or Xray records remain in those external systems and must be managed there.

Transport and application security

In production, browser-to-application traffic is transmitted over HTTPS/TLS provided by the hosting platform. Sensitive operations run server-side. Authorization checks are enforced in API routes, database access occurs through server-side application code, and protected actions require an authenticated user. User-specific data access is scoped by ownership.

Destructive operations use explicit confirmation in the product UI and server-side validation. Account deletion runs inside a database transaction. External billing verification occurs before account deletion, and deletion fails closed if billing status cannot be verified.

Billing security

Stripe processes subscription payments. Checkout and subscription management use Stripe-hosted workflows, including the Stripe Customer Portal. QA Workflow Assistant stores billing identifiers and subscription status required to manage access. Full card numbers and card security codes are not stored by the application.

Account deletion does not automatically cancel an active subscription. Users must cancel through Stripe before deleting an account, and deletion remains blocked while paid access is active. Stripe billing records may remain under Stripe’s legal, accounting, fraud-prevention, and operational requirements.

Data storage and user controls

Users may delete one saved generation, delete all saved generation history, disconnect Jira, remove Xray credentials, and delete their QA Workflow Assistant account. Saved generations remain until deleted or the account is deleted.

Account deletion removes associated live application records from the production database inside a Prisma transaction. Unexpected transaction failures roll back the database deletion. External Jira/Xray items are not deleted. Stripe records are not deleted. Sentry events, hosting logs, backups, and provider records may remain according to operational or legal retention requirements, as described in the Privacy Policy.

AI processing and data minimization

User-provided QA content is sent to OpenAI services to generate output. Submit only content required for the requested generation. Remove passwords, secrets, tokens, payment-card data, health information, unnecessary personal information, and confidential production data before generating. The application displays a Sensitive Data Notice, and users remain responsible for sanitizing and anonymizing Jira content. Review AI output before use or Jira/Xray push.

OpenAI processing is governed by OpenAI’s applicable platform terms and data-handling policies. QA Workflow Assistant does not use customer content to train its own proprietary machine-learning models.

Logging and error monitoring

Sentry monitors application errors and is configured with sensitive-data scrubbing and data-minimization controls. Operational logs are intended to avoid passwords, tokens, user stories, and integration secrets. Account-deletion logs use limited metadata such as user ID, operation name, and deleted-record counts.

Expected authentication failures or active-subscription blocks are not treated as unexpected application errors. Unexpected billing- verification and database failures may be captured for troubleshooting. Logging and monitoring are configured to reduce unnecessary collection of sensitive information. No logging system can guarantee that sensitive data never appears in every edge case.

Rate limiting and abuse prevention

The Service enforces generation limits, Free and Pro plan entitlements, API usage tracking, and account- or IP-based rate limiting where implemented. Server-side entitlement checks, ownership validation, duplicate-protection logic for Jira/Xray pushes where applicable, and billing-status verification help reduce abuse. Sensitive account-deletion decisions fail closed when billing status cannot be confirmed. Current Free limits are shown on the Pricing page and in the product.

Third-party infrastructure

• Vercel — hosting and application delivery
• Supabase — PostgreSQL database infrastructure
• Stripe — payments and subscription management
• OpenAI — AI processing
• Google — optional authentication
• Sentry — error monitoring
• Atlassian Jira Cloud — optional issue integration
• Xray Cloud — optional test-management integration

Third-party providers maintain their own security programs, terms, and privacy practices. Provider certifications do not automatically make QA Workflow Assistant certified. Third-party outages, API changes, or security events may affect the Service. Providers are reviewed and configured based on current product needs.

Secure development practices

Security-sensitive changes are validated through TypeScript type checking, linting, production builds, and targeted manual testing. Secrets are managed through environment-based configuration. Server-side authorization and ownership validation protect user data. Destructive operations are guarded, account deletion uses a database transaction, and external billing checks are kept outside that transaction. Error monitoring and privacy-conscious logging support operational awareness. Encrypted credentials use a versioned format to support future migration.

Shared responsibility

Security is a shared responsibility between the product and the people who use it.

Report a Security Concern

If you believe you have identified a security vulnerability affecting QA Workflow Assistant, please contact info@qaworkflow.net with enough detail to investigate the issue.

Please include:

• Description of the issue
• Affected page or feature
• Reproduction steps
• Potential impact
• Screenshots or logs with secrets removed
• A safe contact method

Please avoid:

• Accessing other users’ data
• Service disruption
• Destructive testing
• Privacy violations

Provide reasonable time to investigate before public disclosure. QA Workflow Assistant does not currently operate a paid bug bounty program.

Contact