What Website Clients Should Know Too — Using IPA's 'How to Secure Your Website' as a Checklist

Ask “is our website’s security okay?” and few companies can answer “yes” with any real basis for it.

It’s easy to assume it’s fine because a design firm is handling it, or that a company-profile-only site isn’t a target — but a single contact form means a program is running to process input, and if you’re using a CMS like WordPress, both the admin screen and every plugin are attack surfaces. What’s more, most attacks don’t target a specific company; they mechanically hunt down weak sites.

So what standard should you actually check “okay” against? The public reference that has long served that role is IPA’s (the Information-technology Promotion Agency’s) How to Secure Your Website.

This article lays out what this reference teaches, in language that makes sense both to the client placing the order and to whoever operates the site.

1. The Bottom Line First

• “How to Secure Your Website” is a reference built from vulnerabilities actually reported to IPA, summarizing 11 categories of website weakness and their countermeasures. It’s useful not just to developers, but as a standard for placing an order and for acceptance
• Countermeasures split into a “fundamental solution” (removes the cause) and a “fallback measure” (reduces the damage). The baseline is the fundamental solution, with fallback measures layered on top
• The accompanying “Security Implementation Checklist” can be used directly as a checklist item both when ordering from and accepting delivery from a development firm
• The supplementary “Website Health-Check Specification” gives you a baseline set of diagnostic items for periodically inspecting a live site
• In practice, for a company site, the two areas where risk concentrates are the parts that accept input, such as forms, and CMS operations (WordPress and the like). Decide, at the time of ordering, on an ongoing operational structure so the project doesn’t end the moment the site is built

2. What Is “How to Secure Your Website”?

“How to Secure Your Website” is a reference IPA compiled for website developers and operators, covering vulnerabilities that were reported to it frequently or that carry a large impact if exploited, along with countermeasures. The latest version currently published is the 7th revised edition, running 115 pages in total. The PDF being distributed is the one that was updated on March 31, 2021 as the 4th printing. Beyond the PDF, HTML pages are also published for each individual vulnerability.

It’s organized into three chapters.

In addition to the main volume, the following are also published:

• Security Implementation Checklist (Excel format): a list for confirming whether the main volume’s countermeasures have been implemented
• Supplementary volume, “How to Call SQL Safely”: a deeper dive on database-related vulnerability countermeasures
• Supplementary volume, “Website Health-Check Specification”: a specification of 13 diagnostic items for assessing a live site

All of these can be downloaded free of charge from IPA’s page.

2.1. How to Think About the Reference’s Currency

There is one piece of background to settle before using this reference as a standard. The 7th revised edition was published in March 2015; corrections have gone in with each subsequent printing, and the PDF distributed today is the 4th printing of that 7th edition, updated on March 31, 2021. As of this writing (July 2026), no 8th edition has been published.

It still works as a standard because what it covers are weaknesses that arise from how web applications are built in the first place. Embedding input values into SQL statements and HTML, identifying a user by session, sending email from what was typed into a form — none of those mechanisms have changed. The 11 categories of vulnerability and the “fundamental solution / fallback measure” framing still hold up as a standard for verifying an implementation.

Put the other way around, this reference cannot cover recent trends in the threat landscape. Ransomware attacks, intrusions by way of a business partner or a subcontractor, risks that come with the use of generative AI — none of those topics were within its scope to begin with. For those, you supplement it with references that are updated every year.

There is no need to read all three separately. It is enough to divide the roles — this reference is the standard for implementation, the 10 Major Threats covers the latest threat trends, the guidelines cover the company’s structure — and go look only at the part you need. The contents of the 2026 edition of the 10 Major Threats are covered in our article on Information Security 10 Major Threats 2026, and the 4.0 edition of the guidelines in our article on the 4.0 edition of the guidelines.

3. Reading the 11 Vulnerabilities as “What Happens If You Do Nothing”

The 11 categories of vulnerability covered in Chapter 1 are laid out in developer-facing terminology, but reframed as “what happens on your own site if you leave it alone,” it becomes clear this isn’t someone else’s problem even for the client placing the order.

The rightmost column gives examples of the places on a company site where the vulnerability tends to become a problem. Whether your own site has the same feature tells you which rows are your problem.

For example, “mail header injection” applies directly to the contact form on a plain company-profile site. A poorly protected form gets abused as a source of spam, damaging even the reputation of the company’s own domain (whether its emails actually get delivered). As covered in “Why Contact Form Emails Aren’t Being Delivered”, a form whose emails stop arriving translates directly into lost business opportunities.

4. “Fundamental Solutions” and “Fallback Measures” — How to Think About Countermeasures

What makes this reference excellent is that it presents countermeasures in two categories.

• Fundamental solution: an implementation that removes the root cause of the vulnerability itself. For SQL injection, for example, building SQL statements with placeholders instead of string concatenation
• Fallback measure: a countermeasure that reduces the success rate or impact of an attack when a vulnerability remains. For example, not displaying raw error messages in the browser

This distinction gives the client a yardstick when hearing an explanation of security. An explanation like “we’re putting in a WAF (a mechanism that detects and blocks attacks), so you’re covered” is talking about a fallback measure — it’s not a substitute for a fundamental solution in the application itself. Conversely, implementing a fundamental solution and then layering a WAF on top is a sound configuration. Simply distinguishing which layer someone is talking about lets you judge the soundness of a proposal considerably better.

5. How to Use It When Ordering and Accepting Delivery

“How to Secure Your Website” is written for developers, but its practical value to the client is that it can be used as a standard for requirements and verification.

• At the quoting/requirements stage: add a line to the specification or RFP saying “implement countermeasures for the vulnerabilities listed in IPA’s ‘How to Secure Your Website.’” Naming a specific standard makes the requirement far more concrete than a vague phrase like “give appropriate consideration to security”
• At acceptance: ask for the confirmation results against the relevant items in the security implementation checklist
• At the contract stage: put in writing who will handle updates to the CMS, plugins, and server after launch, and whether responding to a newly discovered vulnerability falls within the maintenance contract or requires a separate quote

The third point matters especially. A website’s security isn’t finished the moment it’s built — it’s maintained by keeping up with newly discovered vulnerabilities after launch. This question of “who keeps watching over it” is the same structure as the maintenance-scope question covered in our article on custom software development and maintenance contracts.

5.1. Sample Wording for a Specification or an RFP

“Give appropriate consideration to security” never settles what counts as having met the requirement. Naming the reference and the deliverable turns the requirement into something that can be verified. For example, write it like this.

Security requirements

1. For each vulnerability listed in Chapter 1 of IPA’s “How to Secure Your Website, 7th Revised Edition,” the web application in this project shall implement the countermeasures that document classifies as a “fundamental solution.”
2. At delivery, the vendor shall submit self-check results for every item of the “Security Implementation Checklist” accompanying that document. For any item judged “no action required,” the reason (that the site has no such feature, for instance) shall be stated alongside it.
3. For every screen that involves dynamic processing (contact form, search, login, file download, and so on), the design document shall state the policy for handling input values and for escaping on output.
4. The maintenance contract shall state who performs updates to the CMS core, themes, plugins, and runtime environment after launch and how often, along with the response time and the handling of costs in the event that an urgent vulnerability is disclosed.

There is no need to include all four items from the start. For a site that is mostly a company profile, even items 1 and 2 alone make the conversation at acceptance completely different from ordering with “we’ll leave security to you.”

5.2. What Is in the Checklist

The checklist is a single Excel file in which 47 action items corresponding to Chapter 1 of “How to Secure Your Website, 7th Revised Edition” are laid out under each of the 11 categories of vulnerability. Each row consists of the category of vulnerability, the nature of the countermeasure (fundamental solution or fallback measure), a check column (done / not addressed / no action required), the text of the action item, and the section number of the explanation in the main volume.

The actual items are worded something like the following.

(The action-item text is quoted from the security implementation checklist accompanying IPA’s “How to Secure Your Website, 7th Revised Edition.”)

What makes this convenient for the client is that the check column offers “no action required.” On a site with no login feature it is perfectly normal for the session-management items to be blank, but if nothing is written in, there is no way to tell whether that means “not applicable, so no action required” or simply an oversight. Just having “no action required” written in together with a reason makes the acceptance conversation concrete.

6. Give a Live Site a “Health Check”

For a site that’s already live, the supplementary “Website Health-Check Specification” is useful. It’s a specification of diagnostic items (13 in total) for checking the safety of a running website, and it also serves as a rough guide to the scope of what a vulnerability-diagnosis service should cover.

For an SME company site, in practice, risk tends to concentrate in two particular places:

• The parts that accept input: contact forms, search boxes, member login, and so on. Most of the vulnerabilities in Chapter 1 relate to this
• CMS operations: on a site where updates to the core, theme, or plugins of a CMS such as WordPress have stalled, getting tampered with by exploiting a known weakness is the classic pattern. It’s extremely common for nobody to have decided whose job the updates are, and for the site to simply be left as-is

If you want to rethink the CMS-update burden along with the entire operational structure, our article on migrating away from WordPress is also worth a look. There’s also the design decision of reducing dynamic processing altogether in favor of a static site structure, which shrinks the attack surface itself. Our own use of a static site structure built on the Digital Agency’s design system for site production is an extension of the same thinking.

Note that operating a website safely is also listed as a check item in the self-assessment for IPA’s “Information Security Guidelines for Small and Medium Enterprises,” 4.0 edition. For where this fits within a company’s overall security measures, see our article on the 4.0 edition of the guidelines.

7. A Mini Glossary of Terms

Here are the terms this article has used that come up in meetings with a development firm. Once you can state what each one means in a single line, you can judge for yourself, while an explanation is being given, whether it is about a fundamental solution or a fallback measure.

Summary

Here are the key points of IPA’s “How to Secure Your Website.”

• A standard reference (7th revised edition, 115 pages) covering 11 categories of website weakness and their countermeasures, based on vulnerabilities actually reported to IPA
• Countermeasures split into two layers: fundamental solutions and fallback measures. A fallback measure such as a WAF is not a substitute for a fundamental solution
• Clients can use it by naming the reference in their requirements, verifying delivery against the checklist, and settling the post-launch update structure in the contract
• Give a live site periodic health checks using the “Website Health-Check Specification” as your baseline
• A company site’s realistic risk tends to concentrate in input processing such as forms, and in a neglected CMS

Security tends to become a choice between “spend whatever the expert tells you to” or “do nothing at all,” but simply knowing the public standards lets you make requests and verify results in your own words.

For Those Considering Building or Renewing a Website

When building or renewing a website, Komura Software LLC proposes solutions in line with the thinking covered in this article — from how the form is implemented, to a static structure that doesn’t over-rely on a CMS, all the way through the post-launch update structure. We also welcome a consultation starting from a current-state assessment for those who aren’t even sure what state their current site is in.

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

What kind of document is 'How to Secure Your Website'?

It's a security reference published by IPA (the Information-technology Promotion Agency) for website developers and operators. Among the vulnerability reports IPA has received, it covers the ones reported most often or with the greatest potential impact, explaining the threats and the countermeasures. The current 7th revised edition was published in March 2021 and runs 115 pages. Alongside the main volume, IPA also publishes, free of charge, a security implementation checklist and two supplementary volumes: 'How to Call SQL Safely' and the 'Website Health-Check Specification.'

Does even a bare-bones company-profile website need security measures?

Yes. If there's a contact form, a program is running to process the input; if you're using a CMS such as WordPress, the admin screen and plugins are both attack surfaces. Attackers don't necessarily pick targets by company size — they mechanically scan for vulnerable sites and abuse them as stepping stones for tampering, distributing malware, or sending spam. What makes a website dangerous is that you can end up hurting your business partners and visitors at the same time you're a victim yourself.

What's the difference between a fundamental solution and a fallback measure?

'How to Secure Your Website' presents countermeasures in two categories. A fundamental solution is an implementation approach that removes the root cause of the vulnerability itself (for example, using placeholders rather than string concatenation to build SQL statements). A fallback measure reduces the success rate or impact of an attack when a vulnerability remains (for example, not displaying raw error messages). Since fallback measures alone leave the root cause in place, the correct order is to treat the fundamental solution as the baseline and layer fallback measures on top.

What should I check about security when placing an order with a development firm?

At minimum, we recommend confirming three things at the quoting stage: (1) whether the countermeasures listed in 'How to Secure Your Website' are implemented, (2) whether the results can be shown using the accompanying security implementation checklist or similar, and (3) who will handle updates to the CMS and plugins after launch (i.e., whether that's within the scope of the operations-and-maintenance contract). Security requirements are costly to add after the fact, so it's important to confirm them in writing before the contract is signed.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.