1、盡量使用https

https可以過濾掉大部分的安全問題。https在證書申請，服務器配置，性能優化，客戶端配置上都需要投入精力，所以缺乏安全意識的開發人員容易跳過https，或者拖到以后遇到問題再優化。https除了性能優化麻煩一些以外其他都比想象中的簡單，如果沒精力優化性能，至少在注冊登錄模塊需要啟用https，這部分業務對性能要求比較低。

2、不要傳輸明文密碼

不知道現在還有多少app后臺是明文存儲密碼的。無論客戶端，server還是網絡傳輸都要避免明文密碼，要使用hash值?？蛻舳瞬灰鋈魏蚊艽a相關的存儲，hash值也不行。存儲token進行下一次的認證，而且token需要設置有效期，使用refresh

token去申請新的token。

3、Post并不比Get安全

事實上，Post和Get一樣不安全，都是明文。參數放在QueryString或者Body沒任何安全上的差別。在Http的環境下，使用Post或者Get都需要做加密和簽名處理。

4、不要使用301跳轉

301跳轉很容易被Http劫持攻擊。移動端http使用301比桌面端更危險，用戶看不到瀏覽器地址，無法察覺到被重定向到了其他地址。如果一定要使用，確保跳轉發生在https的環境下，而且https做了證書綁定校驗。

5、http請求都帶上MAC

所有客戶端發出的請求，無論是查詢還是寫操作，都帶上MAC（Message Authentication

Code）。MAC不但能保證請求沒有被篡改（Integrity），還能保證請求確實來自你的合法客戶端（Signing）。當然前提是你客戶端的key沒有被泄漏，如何保證客戶端key的安全是另一個話題。MAC值的計算可以簡單的處理為hash（request

params＋key）。帶上MAC之后，服務器就可以過濾掉絕大部分的非法請求。MAC雖然帶有簽名的功能，和RSA證書的電子簽名方式卻不一樣，原因是MAC簽名和簽名驗證使用的是同一個key，而RSA是使用私鑰簽名，公鑰驗證，MAC的簽名并不具備法律效應。

6、http請求使用臨時密鑰

高延遲的網絡環境下，不經優化https的體驗確實會明顯不如http。在不具備https條件或對網絡性能要求較高且缺乏https優化經驗的場景下，http的流量也應該使用AES進行加密。AES的密鑰可以由客戶端來臨時生成，不過這個臨時的AES

key需要使用服務器的公鑰進行加密，確保只有自己的服務器才能解開這個請求的信息，當然服務器的response也需要使用同樣的AES

key進行加密。由于http的應用場景都是由客戶端發起，服務器響應，所以這種由客戶端單方生成密鑰的方式可以一定程度上便捷的保證通信安全。

7、AES使用CBC模式

不要使用ECB模式，記得設置初始化向量，每個block加密之前要和上個block的秘文進行運算。

7.main()之前的過程有哪些？

1、main之前的加載過程

1）dyld 開始將程序二進制文件初始化

2）交由ImageLoader 讀取 image，其中包含了我們的類，方法等各種符號（Class、Protocol 、Selector、 IMP）

3）由于runtime 向dyld 綁定了回調，當image加載到內存后，dyld會通知runtime進行處理

4）runtime 接手后調用map_images做解析和處理

5）接下來load_images 中調用call_load_methods方法，遍歷所有加載進來的Class，按繼承層次依次調用Class的+load和其他Category的+load方法

6）至此 所有的信息都被加載到內存中

7）最后dyld調用真正的main函數