Back to the collection
security-best-practices·Development

security-best-practices: review secure defaults for the actual stack (legacy standalone Skill)

This guide covers an older version from the deprecated openai/skills repository. Check the current official project before installing. Current OpenAI plugins

On this page

Use this Skill for an explicit security review or secure-by-default implementation request. It identifies the project’s languages and frontend and backend frameworks before selecting relevant reference material. Existing code can produce a prioritized report with locations; new work can use the same guidance to define implementation expectations.

Install and prepare

This guide covers the standalone Skill retained in openai/skills. That repository is deprecated and current examples have moved to openai/plugins; the instructions here describe the linked standalone version, not the latest plugin.

Enter this line in the Codex conversation, not a terminal. If the installed Skill does not appear, restart Codex.

Prompt
$skill-installer security-best-practices
  • Readable project source and dependency information
  • An explicit security scope and deployment context
  • This standalone version primarily supports Python, JavaScript/TypeScript and Go

Try a first task

Start with a bounded area, such as authentication and uploads:

Prompt
$security-best-practices
Review security best practices for authentication, sessions and file uploads in this project. Identify both stacks and deployment assumptions, then read the relevant guidance. Write evidence-backed findings to security_best_practices_report.md with severity, file and line, impact and repair direction. Report only for now. Treat unsupported risks as questions, not confirmed flaws.

Work through the task

  1. Select relevant guidance. Identify languages and frameworks from code and dependencies, including both frontend and backend. State when matching reference material is unavailable.

  2. Make findings locatable. Include file, line and impact. Distinguish an existing defect from a concern that depends on a particular deployment assumption.

  3. Choose focused repairs. Select priorities after reading the report. Preserve intended behavior, verify the relevant risk and record remaining issues.

Review one security finding end to end

Choose a high-priority finding and trace “external entry → relevant code → existing validation → sensitive operation.” The report should state the attacker’s required permission, deployment preconditions and potential impact. A file location without the conditions is not enough to prioritize work. If production configuration is unavailable, keep the claim conditional and ask the deployment owner to confirm it. After a fix, test both that the attack path is blocked and that intended users can still complete the flow.

Do not confuse a report with a safety certificate

“No finding” means none was identified within the examined scope and visible code, not that no vulnerability exists. External services, runtime configuration, secret handling and network boundaries may be outside the repository. After a fix, check that intended permissions still work and document unverified external conditions. A standalone code review is not penetration testing or compliance certification.

Another case: both frontend and backend are in scope

A public file-sharing app may use TypeScript on the frontend and Go on the backend. Ask: “Review share-link creation and download. Identify both frameworks and read the matching security references in the Skill. For each code-grounded finding, give a numbered ID, severity, file and line, precondition and proposed fix. Do not call missing TLS in local development a production vulnerability by itself.” This checks that neither layer was skipped and makes the report reviewable item by item. The standalone Skill normally writes security_best_practices_report.md; spot-check whether high-risk findings can really be traced from entry point to sensitive operation. Address one finding at a time and run relevant tests.

Check the result

Start by checking whether the highest-priority findings point to real code and use assumptions that match your system. A report should explain impact rather than merely assign labels. After fixes, describe what was verified instead of claiming the entire system is secure.

Common blockers

The language is unsupported. Use guidance specific to that language or framework instead of overstating this Skill’s coverage.

A recommendation breaks intended behavior. Ask for the conflict and migration options, documenting justified exceptions.

The report is generic. Require a code location and relevant conditions for each finding; remove items that cannot be connected to the project.

Keep the language references and verify each finding

Scope the review to a language and concrete entry points, such as authorization and input handling in a Node API. Keep the full installed skill directory rather than copying only SKILL.md, since language references inform the checks. For each finding, inspect the code path and use a test or minimal reproduction to separate an exploitable risk from a general recommendation.

How did your first task go?

These choices help us understand where readers get stuck through site analytics. Blocking analytics may prevent delivery; use email for a specific issue.

References

  1. security-best-practices: standalone Skill instructionsOpenAI
  2. openai/skills repository status and installationOpenAI
  3. Codex: build and install SkillsOpenAI
  4. OpenAI Official Security-Best-Practices: Performing Security Reviews of AI According to Languages and FrameworksYeyupiaoling
Found outdated or incorrect information? Let us know