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 current version is the 7th revised edition, published in March 2021, running 115 pages in total. 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.

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.

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 outsourced development and maintenance contracts.

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.

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.