第一天 (6.26)
从国哥那里得到了最终项目的要求和相关资料
SDLC（Software Development Life Cycle），即软件生命周期，，是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。但随着新的的设计方法和技术的成熟，设计方法的指导意义正在逐步减少。
需求安全建议
第二天 (6.27)
写ELV需求文档 大创报销第一次书籍购买 Dying...
第三天 (6.14)
过程中可进行的优化可按阶段划分：优化可在编译的不同阶段进行，分为 一级和 一级的优化。可按优化涉及的程序范围划分：对同一阶段，分为局部优化,循环优化和全局优化. 进行优化所需要的基础是对代码进行数据流分析和 分析。如划分 ，查找循环，分析 的定值点和引用点等等。最常用的代码优化技术有删除多余运算，循环不变代码外提，强度削弱，变换循环控制条件，合并已知量与复写传播，以及删除无用赋值等等。
·动态网页使用语言：HTML+ 或HTML+ 或HTML+ 等。
·动态源码：ASP、PHP、JSP、.net、CGI等等,动态源码最大的特点就是能够和用户之间互动。
在编译原理中,局部优化指在程序的一个基本块内进行的优化。[1]
一顺序执行的最大语句序列，只有惟一入口和惟一出口，且分别对应该序列的第一个语句和最后一个语句 。[1]
基本块内的语句是顺序执行的，没有转进转出，分叉汇合 。[1]
根据基本块的结构特点，它的入口语句是下述三种类型的语句之一:⑴ 程序的第一个语句；⑵ 由条件转移语句或无条件转移语句转移 到的语句；⑶ 紧跟在条件转移或无条件转移后面的语句。[1]
第2步：根据确定的基本块的入口语句，构造其所属的基本块。[1]
⑴ 由该入口语句直到下一个入口语句(不包含下一个入口语句)之间的所有语句构成一个基本块；⑵ 由该入口语句到程序中的停止或暂停语句或最后一个语句(包含该停止或暂停或最后语句)之间的语句序列组成的。[1]
第3步：凡是未包含在基本块中的语句，都是程序的控制流不可到达的语句，直接从程序中删除。[1]
一. 尽量采用 布局您的页面，div+css布局的好处是让 爬虫能够更顺利的、更快的、更友好的爬完您的页面；div+css布局还可以大量缩减网页大小，提高浏览的速度，使得代码更简洁、流畅、更容易放置更多内容。
二. 尽量缩减您的页面大小，因为 爬虫每次爬行您的站点时，存储数据的容量有限，一般建议100 以下，越小越好，但不能小于5KB。网页大小减少还有一个好处，能够促使您的站点形成巨大的内部链接网。
三. 尽量少用无用的图片和 。内容索引所派出的 爬虫，不认识图片，只能根据 “ , ”等属性的内容判断图片的内容。对于 爬虫更是视而不见。
四. 尽量满足 标准， 的编写满足W3C标准，能够提升网站和 的友好度，因为 收录标准，排名算法，都是在 标准的基础上开发的。
五. 尽量更深层次套用标签 、h2、h3、h4、h5…..，让 能够分辨清晰网页那一块很重要，那一块次之。
六. 尽量少用 ，JS代码全部用外部调用文件封装。 不喜欢JS，影响网站的友好度指数。
七. 尽量不使用 布局，因为 对表格布局嵌套3层以内的内容懒的去抓取。 爬虫有时候也是比较懒的，望各位一定要保持代码和内容在3层以内。
八. 尽量不让CSS分散在HTML标记里，尽量封装到外部调用文件。如果CSS出现在 标记里， 爬虫就要分散注意力去关注这些对 没有任何意义的东西，所以建议封装到专用CSS文件中。
九.清理垃圾代码，要把代码编辑环境下敲击键盘上的 所产生的符号；把一些默认属性代码，不会影响显示的代码；注释语句如果对代码可读性没有太大影响，清理这些垃圾代码，会减少不少的空间。
html代码是最为基础的网站制作语言，对于网站优化来说，html代码也有一定的影响，是特别需要注意的优化细节之一。
title标签就是网页的标题，是一个对于网站优化有很大影响的html标签，每个页面都必须有且内容不同！基本格式为<title>网页标题。</title>
meta元素在浏览器界面是无法看到的html标签，对于优化有影响的主要有两个，一个是关键字（keywords）、一个是描述（description）。其实，这两个标签随着seoer的胡乱使用，对于网站优化已经没有多少用处了，你完全可以不用设定，但我们还是习惯性的设置一下较为妥当。关键字，设定与本页内容相关的主关键词一到三个，之间用英文状态下的逗号分割。需要注意的是，不要再滥用关键字，除了给搜索引擎不好的印象外别无他用。描述还是很有用的一个东东了，虽然对于网站的优化排名么有多大的影响，但会作为搜索引擎展示网站索引的一个依据，可以把你的主关键字链接起来组合成一段通顺的话，一般60到80字即可。格式为:
<meta name="keywords"content="">
<metaname="description"content="">
h标签在html代码中是“标题”的意思，就如一篇文章，标题是文章最为重要的一个对象，也是搜索引擎在排名时重点考虑的一个对象。html中的h标签一共有六个，分别是h1/h2/h3/h4/h5/h6，分别代表不同的级别，我们称之为一级标题、二级标题……当然，一级标题具备更多的权重。需要注意的是h标签是块级元素，默认是粗体显示，独占一行，前后会有空行。当然，你可以利用css来改变这些效果。
关于h标签的使用，需要根据实际情况来使用，不可任意滥用。如一篇文章，不可能出现多个一级标题，所以h1，在同一个页面中只能出现一次，而h2等则可以出现多次，根据你需要表现的内容的重要程度，分别使用不同的h标签即可。特别注意，h标签中最好出现关键字！还有就是，随其自然，万不可刻意地用h标签来处理某些关键字！
strong被认为是“加强”，em被认为是“强调”，也就是这两个标签是有特殊含义的，这对于网站优化至关重要。多数时候，我们在优化网站时会对关键字进行突出，这时使用strong或em就比使用B或者I好很多，特别谨记！
alt是图像中的注释，title是图像或链接的标题，这两者对于优化，尤其是图像的优化至关重要，但也不要滥用！一般在插入图像时，我们在alt中设置图像的描述内容，其中可以包含关键字但不要故意堆砌，title则当作图像标题来处理。特别需要注意的是，这些内容是不可以重复的！也就是说，当你的页面中有多张图像，你不能每张图像的描述和标题都设置成一样的，这样很容易被搜索引擎惩罚！
<img src="test.jpg"alt="一个美女站在黄昏的街头默默等待爱人的回归，眼神中充满了忧伤"title="静待">
除此之外，title属性在a标签中也有所使用，只是有些泛滥了，视觉效果也不好，影响用户体验，所以笔者并不推荐，除非你的a标签中的内容是一张图片。
<a href="product.html"title="产品展示">产品展示</a>
这个标签是自定义的一种缩写方式，可以利用它合理的添加一些关键字，同样不要滥用。如下所示：
公司的产品涉及<abbr title="以石材为原料的雕刻作品">石雕</abbr>、<abbr title="以铜料为胚，运用雕刻、铸塑等手法制作的一种造型艺术">铜雕</abbr>、<abbr title="附属在某一平面上的雕刻艺术">浮雕</abbr>、镂雕等各种雕刻形式。
Canonical[3] (权威链接标记)是09年，Google，Yahoo及Microsoft三大搜索引擎联合推出了一个旨在减少重复内容的一个建议，并不是命令，也就是说这个标签搜索引擎可能不遵守。国内最大的中文搜索引擎百度也已经支持Canonical标签。
部分搜索引擎引入了Link的一个新属性Canonical。A页面声明B为权威链接，B声明C为权威网页，则搜索引擎会认为C是A和B共同的首选权威版本。此时Canonical标签起到了301重定向的作用。
只能作用于同一个域名所在的网址，不能作用于不同域名上的重复内容。也就是说如果文章被其它网站抄袭，也不会因为这个标签而给你的原文章带来权重。如果是跨站，可以使用301重定向。该链接标签可用于定义 ，也可用于定义 。但为了保险起见，建议使用 。
使用方法：为网页指定权威链接（authoritative|canonical URL），以解决副本内容（duplicate content）问题。
使用样式：<link rel=”canonical” href=”网页权威链接”/>
于网站排名优化来说，css的几乎没有任何影响，但往大的方向如网站优化来说，样式表css的优化就至关重要了，其主要作用即是提高网页的响应速度。
css的使用有多种方式，一是嵌入式，即在html标签中直接定义样式表，如下所示:<p style="font-family:arial;font-size:16px;font-weight:bold;">Outside now its raining,and tears are falling from my eyes…</p>
还有一种是直接定义在页面头部的如下：<styletype="text/css">p{ background:#f1f1f1; color:#333; line-height:20px;} </style>
这两种方式都是把css写在当前html中，这样会造成hml文档变大，降低网页的响应速度，所以我们需要外链css，将所有与本页面相关的样式写入到该样式表中：<link href="style/common.css"rel="stylesheet"type="text/css"/>
对于这一点需要一定的css能力才可以做到了。所谓精简，指的是用尽可能少的样式代码实现整个网页的样式效果，需要充分利用css的继承和综合使用，举一个简单的例子来说明。如页面中的链接，全部不需要下划线、大部分为12像素，但链接的颜色并不相同，个别的字体效果也不相同，我们就可以这样来写：
a{ text-decoration:none; font-size:12px;}/*定义通用a样式*/
a.a_red{ color:#e00;}
a.a_blue{ color:#009;}
a.a_menu{ color:#fff; font-size:14px; font-weight:bold;}/*针对特殊a标签只指定特殊样式*/
因为css的继承作用，a_red和a_blue都具备没有下划线、12像素这一样式，而a_menu同样具备没有下划线，但因指定了大小，就不再继承12像素的指定而使用14像素……
一般情况下，前端制作人员喜欢把通用样式写成一个文件，把专用样式写成另一个文件以便各个页面调用。如笔者，就喜欢把页面通用样式（包括通用的布局样式、文字样式等）写在common.css中，而把专用的写在另一个样式表中。如首页，我们就需要调用common.css和index.css两个样式表文件。这样做，对于前端来说是正确的。但对于优化，却不太好。多一个文件调用就需要多一次请求，当然也会多耗费一点时间。所以，在网站制作完成后，我们需要把页面的所有样式合并大一起以提高网页的响应速度！但需注意，合并css不利于网站后期整改，权衡利弊各取所需吧，具体是否合并还需根据你的实际情况而定。
压缩css其实很简单，就是去掉多余的空格和换行。实现起来也非常的简单，网上有很多工具，请自行搜索“css压缩”即可找到很多在线压缩工具。同上面一点，压缩后的css不便于后期整改，需要自己权衡取舍。
javascript代码对于网站排名优化同样没有多大影响，但从网站优化的角度来看却是至关重要的一步优化操作，优良的javascript代码可以大幅度提升网页的响应速度！
内部定义：<A οnclick="if(confirm('确认？'){...}else{...})"href="#">confirm</A>
头部插入：<script>...</script>
外链调用：<SCRIPT language=javascript type=text/javascript src="jquery-1.7.2.min.js"></SCRIPT>
这一点需要更为专业的js技术才能做到，尽可能根据需要实现的效果编写js，而不用从网上找一段代码直接拿来用，网上的代码很多功能很全，从而质量很大，而其中的很多功能对于我们要实现的效果是没有任何用处的，所以广拓企业网站建议你针对需要实现的效果定制js以便得到更为精简的代码，从而提高网页的响应速度。
对于这点，网上也有很多的工具，请百度查询“js压缩工具”即可。
一般情况下，我们都是把js放到head之间的，这种方式在页面加载时即会加载，当然也就导致响应速度的降低，百度站长平台建议把js放到页面最底部，也就是</html>之外。等html加载完毕之后才加载js代码，当然，有部分特殊功能的js代码是没有办法放到页面底部的，具体请根据实际情况操作。
补充说明：针对js图像特效等，可能会影响网站关键字排名的！有的特效图像的路径、说明等都是写入到js中的，这种特效尽量不要使用。
在优化工作开始的时候，你还尚未明确优化内容和目的，那么你很容易陷入误区。在一开始，你就应该清楚地了解你要达到的效果，以及其他优化相关的各种问题。这些目标需要明确指出（至少精通技术的项目经理可以理解和表达它），接下来，在整个优化过程中，你需要坚持这些目标。
在实际的项目开发中，经常会存在各种各样的变数。可能一开始时要优化这一方面，随后你可能会发现需要优化另一方面。这种情况下，你需要清晰地了解这些变化，并确保团队中的每个人都明白目标已经发生了变化。
选择正确的指标，是优化的一个重要组成部分，你需要按照这些指标来测量优化工作的进展情况。如果指标选择不恰当，或者完全错误，你所做的努力有可能白费了。
即使指标正确，也必须有一些辨别。在某些情况下，将最多的努力投入到运行消耗时间最多的那部分代码中，这是实用的策略。但也要记住，Unix/Linux内核的大部分时间花费在了空循环上。
需要注意的是，如果你轻易选择了一个很容易达到的指标，这作用不大，因为没有真正解决问题。你有必要选择一个更复杂的、更接近你的目标的指标。
这是有效优化的关键。找到项目中与你的目标（性能、资源或其他）相背的地方，并将你的努力和时间用在那里。
举一个典型的例子，一个Web项目速度比较慢，开发者在优化时将大部分精力放在了数据库优化上，最终发现真正的问题是网络连接慢。
另外，不要分心于容易实现的问题。这些问题尽管很容易解决，但可能不是必要的，或与你的目标不相符。容易优化并不意味着值得你花费工夫。
在一般情况下，优化的层次越高，就会越有效。根据这个标准，最好的优化是找到一个更有效的算法。举个例子，在一个软件开发项目中，有一个重要的应用程序性能较差，于是开发团队开始着手优化，但性能并没有提升太多，之后，项目人员交替，新的开发人员在检查代码时发现，性能问题的核心是由于在表中使用了冒泡排序算法，导致成千上万项的增加。
尽管如此，高层次的优化也不是“银弹”。一些基本技术，如将所有东西移到循环语句外，也可以产生一些优化的效果。通常情况下，大量低层次的优化可以产生等同于一个高层次优化的效果。
还需要注意的是，高层次优化，会减少一些代码块，那么你之前对这些代码块所做的优化就没有任何意义了，因此，刚开始就应该考虑高层次的优化。
在项目早期就进行优化，会导致你的代码难以阅读，或者会影响运行。另一方面，在项目后期，你可能会发现之前所做的优化没有起到任何作用，白白浪费了时间和精力。正确的方式是，你应该将项目开发和优化当作两个独立的步骤来做。
你往往会认为你已经知道哪里需要优化，这是不可取的，尤其是在复杂的软件系统中，性能分析数据应该是第一位的，最后才是直觉。
优化的一个有效的策略是，你要根据所做工作对优化效果的影响来进行排序。在开始工作之前找到影响最大的“路障”，然后再处理小的“路障”。
优化最重要的规则之一是，你无法优化一切，甚至无法同时优化两个问题。比如，优化了速度，可能会增加资源利用；优化了存储的利用率，可能会使其他地方放慢。你需要权衡一下，哪个更符合你的优化目标。[4]
第四天 (6.15)
第五天 (6.16)
总结实训
技术经验总结: OWASP构建安全应用的十大控制措施
参数化查询
SQL注入是Web应用中最危险的漏洞之一，因为SQL注入较为容易被黑客探测到并且会给应用带来毁灭性的打击。只需在你的Web应用中注入一条简单的恶意SQL，你的整个数据库可能就会被窃取、擦除或者篡改。在运行数据库的主机上，甚至可以借助Web应用执行危险的操作系统命令。
为了防止SQL注入，开发人员必须阻止那些不可信任的输入，这些输入将会解析成为SQL命令的一部分。要实现这一点，最好的一种方式就是使用被称做查询参数化（Query Parameterization）的编程技术。
例如，在Java之中，查询参数化如下所示：
String newName = request.getParameter("newName"); String id = request.getParameter("id"); PreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEES SET NAME = ? WHERE ID = ?"); pstmt.setString(1, newName); pstmt.setString(2, id); 在PHP之中，查询参数化样例如下所示：
$email = $_REQUEST[‘email’]; $id’= $_REQUEST[‘id’]; $stmt = $dbh->prepare(”update users set email=:new_email where id=:user_id”); $stmt->bindParam(':new_email', $email); $stmt->bindParam(':user_id', $id);
对数据进行编码
编码（encoding）是一个很强大的工具，它有助于防范很多类型的攻击，尤其是注入攻击。本质上来讲，编码就是将特殊字符转换成对等的字符，但是转换后的字符对于目标解析器来说不再是敏感的。关于编码的一个样例就是防止跨站脚本攻击（XSS，Cross Site Scripting）。
Web开发人员经常会动态地构建Web页面，页面中包含开发人员构建的HTML/JavaScript代码以及数据库中的数据，而这些数据最初是由用户输入的。输入的数据应该被视为不可信任且危险的，在构建安全的Web应用时，需要对其进行特殊的处理。当攻击者欺骗你的用户执行恶意的JavaScript时，就会发生跨站脚本攻击或者更恰当地称之为JavaScript注入，这些JavaScript脚本最初是构建到Web站点中的，XSS攻击会在用户的浏览器中执行，因此会产生各种各样的影响。
例如，XSS站点涂改：
XSS session窃取：
持久化XSS（Persistent XSS）或存储XSS（Stored XSS）指的是XSS攻击嵌入到了站点的数据库或文件系统之中了。这种XSS更为危险，因为当攻击执行的时候，用户已经登录站点了。当将XSS攻击置于URL的结尾处时，会发生反射XSS（Reflected XSS），它会欺骗受害者访问该URL，当访问的时候攻击就会触发。
阻止XSS的关键编程技术就是输出编码，它会在输出的时候执行，如果你构建用户界面的话，也就是在将非信任的数据添加到HTML中的时候。能够阻止XSS的编码形式包括HTML实体编码、JavaScript编码以及百分号编码（也称为URL编码）。
校验所有的输入
编写安全应用时，很重要的一点就是将所有来自于应用外部的输入（如来自于浏览器或移动客户端，来自于外部系统或文件）均视为不可信任的。对于Web应用来说，这包括HTTP头、cookies以及GET和POST参数，总而言之也就是任何攻击者可以入侵的数据。
构建安全Web应用的一个重要方法就是限制用户能够提交到Web应用之中的输入。限制用户输入的技术称之为“输入校验”。在Web应用的服务器端，输入校验通常会用到正则表达式。
有两种输入校验，分别为“白名单”和“黑名单”校验。白名单试图定义好的输入是什么样子的，任何不匹配“好输入”定义的输入都会被拒绝。“黑名单”校验会试图探测已知的攻击，只会拒绝这些攻击和非法字符。黑名单校验更为困难，因为可以通过编码或其他伪装技术绕过，所以在构建安全Web应用时并不推荐使用。
但有些时候正则表达式是不够的，如果你的应用要处理markup，也就是不受信任的输入中会包含HTML片段，这样的话会很难进行校验，编码也是很困难的，因为编码的话会破坏输入中的标签。此时，会需要一个能够解析和清理HTML格式文本的库，如。
实现适当的访问控制
授权（Authorization，Access Control）过程指的是请求要访问特定资源时，需要判断该请求是该准许还是拒绝。访问控制可能会非常复杂，在应用开发的初始阶段，需要考虑到一些“积极”的访问控制设计需求。在软件的安全设计中，访问控制是很重要的一块内容，因此事先需要进行充分考虑：
强制所有的请求都通过访问控制检查
大多数的框架和语言只会检查程序员指定的特性，但是与之相反的做法是更以安全为中心的。可以考虑使用过滤器或其他的自动化机制以保证所有的请求都要经历某种类型的访问控制检查。
结合自动化的访问控制检查，需要考虑拒绝访问所有没有配置访问控制的特性。但是通常情况下会采取相反的做法，也就是新创建的特性会自动允许所有用户访问，直到开发人员为其配置了安全检查的功能。
在代码中，要避免硬编码基于策略的访问控制检查
通常情况下，访问控制策略是硬编码在应用之中的。这样的话，审计或证明软件的安全性会变得非常困难且耗时。如果可能的话，访问控制策略和应用代码应该分离开来。
在大多数的Web框架中会将基于角色的访问控制作为主要方法。尽管在访问控制机制中，使用角色是可以接受的，但是在应用代码中针对特定的角色编码是一种反模式。在代码中要考虑用户是不是有权限访问某个特性，而不是检查用户具备什么样的角色。
驱动访问控制检查的是服务端的可信数据
在作出访问控制决策的时候，会涉及到很多的数据（登录的用户是谁、这个用户具备什么样的权限、访问控制策略是什么、请求的特性和数据是什么、时间是什么、地理位置是哪里），这些数据应该通过“服务器端”标准的Web或Web服务应用来获取。策略数据，如用户角色和访问控制规则决不能作为请求的一部分。在标准的Web应用中，访问控制唯一需要的客户端数据就是要访问数据的id。作出访问控制决策的大多数其他数据需要从服务器端获取。
建立识别和认证控制
认证过程指的是校验个人或实体是不是就是其所宣称的那个人。通常来讲，认证需要提交用户名或id，以及只有指定用户才能知道的一条或多条私人信息。
会话管理指的是服务器端要维护与之交互的实体的状态。这就需要服务器能够记住整个事务期间如何与后续的请求进行交互。在服务器端，会话通过一个会话标识符来进行维护。
识别管理是一个很广泛的话题，不仅仅包括认证和会话管理，还包括一些高级话题，如联合身份验证（identity federation）、单点登录、密码管理工具等等。
保护数据和隐私性
当传输敏感的数据时，不管是在应用或网络架构的哪一层，都需要考虑以某种方式进行传输加密。对于应用传输加密来讲，SSL/TLS是目前最常见和广泛支持的一种模型。
关于数据安全，很重要的一点在于要对系统中的数据进行分类，并确定哪些数据需要进行加密。 另外，还要保护正在处理中的数据，这些数据位于内存之中，可能更易于获取到。
实现日志和入侵探查
应用的日志不应该是事后才考虑的事情，也不应该局限于调试或解决问题，它应该在其他重要的事情上发挥作用。安全事件的日志与进程监控、审计或事务日志在采集的目的上往往是不一样的，因此通常会进行区分。日志不要记得太多也太能太少，需要记住的一点是不要记录私人或敏感数据。为了防止日志注入（Log Injection），在记录前要对非信任的数据进行校验或编码。
定义了概念化的框架和方法论，通过规范化的指导为已有的应用实现侵入探测和自动化响应。
使用框架和安全库的安全特性
如果对于每个Web应用都从头开发安全控制功能的话，那会非常浪费时间并且会产生大量的安全漏洞。安全的代码库可以帮助开发人员注意安全相关功能的设计，并避免实现中漏洞。
如果可以的话，要尽可能使用框架已有的特性，而不是引入第三方库。可以考虑的Web应用安全框架包括：和。还有一点就是要及时更新这些框架和库。
将安全相关的需求考虑在内
在软件开发项目的初期，需要定义三类安全相关的需求：
安全特性和功能：系统中可见的安全控制，包括认证、访问控制以及审计功能。这些需求通常会包含在用例或用户故事中，Q/A人员可以评估和测试功能的正确性。
业务逻辑的滥用场景（abuse cases）：业务逻辑通常是包含多个步骤、多个分支的工作流程，这些需求的用户故事或用例应该包含异常和失败的场景，并且包含在“滥用场景”下的需求。滥用场景描述了在遭到攻击者破坏时，一项功能该是什么样子的。考虑到失败和滥用场景会发现校验和错误处理中的弱点，从而提升应用的可靠性和安全性。
数据分类和隐私的需求：开发人员应当时刻注意系统中任何的私人和敏感数据，并确保它们是安全的。这会促使在系统中采用数据校验、访问控制、加密、审计以及日志控制等功能。
在设计和架构时，将安全考虑在内 在进行系统的架构和设计时，有一些安全相关的因素需要进行考虑，包括： 了解你所拥有的工具：你所选择的语言和平台会产生技术相关的安全风险和考量因素，开发团队必须要有所理解并进行管理。 分层、信赖以及依赖：在安全的架构和设计中，另外一个很重要的部分就是分层和信赖。确定在客户端、Web层、业务逻辑层以及数据管理层要进行什么样的控制，以及不同系统间或同一个系统的不同部分之间，在什么地方建立信赖关系。信赖的边界确定了应该在什么地方进行认证、访问控制、数据校验和编码、加密以及日志记录。当对系统进行设计或设计变更时，要确保对信赖假设有充分的理解，并且这些假设是合法且一致的。 管理受攻击面：注意系统的受攻击面（attack surface），也就是攻击者可以攻入系统、获取数据的方式。当你增加受攻击面时，要进行风险评估。你是不是引入了新的API或改变了系统中具有较高安全风险的功能，或者只是为已有页面或文件添加一个新的域？
